[9fans] Can't install Plan9 on VMWare
Hi! I've downloaded the Plan9 iso from http://plan9.bell-labs.com/plan9/download.html and tried to test the live cd. It wasn't really possible, at first the boot manager won't really react (the trick seems to wait a long time...) and then some error appears. But since I decided to install it on VMWare on Linux, this doesn't matter so much. There in the installation menu (textinst) I select all the default options and I end up (when doing copydist) with: cacheAllocBlock: xxx1 disk is full and so on... I also made a test doubling each partition's size (exept for nvram) and I ended up with some error that told me IIRC that for my large disc FAT16 doesn't work out, so I would have to use FAT32. Trying to increment each partition lowly (starting from the default size) doesn't help either - moreover the error can even occur early with larger sizes. BTW the VMWare image has a size of 800MB (initially the image size was smaller) and the - default - partition sizes are the following: 9fat 100 MB nvram 512 Bytes fossil 200 MB swap 100 MB Can anyone help me? Philip
Re: [9fans] Can't install Plan9 on VMWare
> you don't need to increase the size of 9fat, either and you > don't need a swap partition at all. with 800mb i would partition > the disk like: > > 9fat 20mb > nvram 512 bytes > fossil700 mb Thank you for your help! This worked out... But now there's a new problem: After installing it and rebooting the computer, everything seems normal until the message "init: starting /bin/rc". Nothing happens then although the computer does not freeze (keyboard input is shown on the screen). Philip
Re: [9fans] Can't install Plan9 on VMWare
> Remove the CD-ROM drive from your VMware configuration and boot. > > John Thanks a lot! Problem solved... Still weird :-) Philip
Re: [9fans] Can't install Plan9 on VMWare
> you either remove the cdrom from the virtual machine or make it to > emulate scsi. > if you're iso is more than 2 days old, you'll have to do > % echo hwaccel off > /dev/vgactl > to get vga working well. I see, well I removed the cdrom. But when installing plan9 I entered ega (or was it cga?!) in order to not start rio. Maybe I should just run through the installation process again - which is extremely slow here. Anyways, text mode now works fine, but when I'm changing /dev/vgactl with "echo type vesa > /dev/vgactl" and "echo hwaccel off > /dev/vgactl" after a reboot the file turns out to be the old one looking like this: type cga bland time 30 idle 0 state on hwaccel on hwblank off panning off addr p 0x0 v 0x0 size 0x0 BTW: When I enter "echo type vga > /dev/vgactl" i get echo: write error: bad VGA control message "type vga". And it seems that I cannot edit the file with ed. Philip Silva
Re: [9fans] netsurf or opossum
To be fair I think the rendering quality can be attributed to the html/css processing. For instance parsing is completely done by golang.org/x/net/html and github.com/aymerick/douceur. (Also one can get quite far with handling display: inline/inline-block/flex and height/width attributes) One disadvantage might be that some existing HTML styling attributes aren't implemented yet like colspan or "standard" tags like textarea or radio inputs although that's easy to implement. Also it's quite speculative how far one could get with JS which is essentially based on goja and domino. But it's promising that jQuery click handlers work in isolated examples, despite the onclick attribute not even being implemented. Probably it's also worth mentioning that memory consumption is comparable to that of a regular browser on macOS. Maybe this could be solved by some kind of tree slicing. In any case I think developing is fun most of the time! Greetings, Philip ‐‐‐ Original Message ‐‐‐ Am Donnerstag, 7. Januar 2021 09:28 schrieb Mark van Atten : > http://git.pmikkelsen.com/ph/opossum > > - > > 9fans: 9fans > Permalink: > https://9fans.topicbox.com/groups/9fans/T9a725c37f61954a8-Mf2d9006c5749e4decf646828 > Delivery options: https://9fans.topicbox.com/groups/9fans/subscription -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9a725c37f61954a8-Mc647b1b9c4ce279c9a88b6a4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation
Awesome!!! ‐‐‐ Original Message ‐‐‐ Am Dienstag, 23. März 2021 14:06 schrieb : > We are thrilled to announce that Nokia has transferred the copyright of > Plan 9 to the Plan 9 Foundation. This transfer applies to all of the > Plan 9 from Bell Labs code, from the earliest days through their final > release. > > The most exciting immediate effect of this is that the Plan 9 Foundation > is making the historical 1st through 4th editions of Plan 9 available > under the terms of the MIT license. These are the releases as they > existed at the time, with minimal changes to reflect the above. > > 1st and 2nd edition were never released as open source software, and > both (but especially 1st edition) were only available to a very small > number of people. 3rd and 4th were previously available as open source, > but under a license which was problematic for some people (especially > the 3rd edition). We think making these available under the MIT license > is something that's going to be a significant benefit for all projects > using Plan 9 code. While this doesn't automatically change the license > on any downstream projects, and you're welcome to keep using the LPL if > you like, you now have the option of switching to MIT, which we think > most everyone will find preferable. > > Obviously, for folks in the Plan 9 community, there isn't a way to say > "thank you" to Bell Labs, and its various parent organizations, that's > really adequate. None of us would be talking about any of this if it > weren't for the work done there for decades. All of us here at the Plan > 9 Foundation express our sincerest thanks to the team at Nokia who made > this possible, the Plan 9 alumni who supported the effort, and the Plan > 9 community who have kept kernels booting and the userland useful. > > The historical releases are available right now at: > https://p9f.org/dl/ > > You can read Nokia's press release on the transfer here: > https://www.bell-labs.com/institute/blog/plan-9-bell-labs-cyberspace/ > > Thank you for your time, > Anthony Sorace > Plan 9 Foundation > > - > > 9fans: 9fans > Permalink: > https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-M63f81768e4ffdfa4df402ec5 > Delivery options: https://9fans.topicbox.com/groups/9fans/subscription -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-M58408e44dcf6a9bbe96f4067 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] amd64 bootstrap file fo go1.16.3
About Go 1.16.3, I had initially another problem when compiling. While running the compiler expected the bootstrapping files to be in a certain path. I think something like /tmp/glenda/.../..., so I renamed the path and it worked. I didn't check further though, but I'll check again later. Otherwise it worked, although I only did make.rc without the tests. True, I noticed for instance light grey tones might show up as white. That's on a external Dell screen which is not the newest. On the fancy Macbook Air screen it's the grey. (E.g. on google.com, which is supposed to have a white background anyway ;)) The conversion from hex to draw.Color is really crude right now, so maybe it only works when the screen has a lot of gamut. Apart from that both vesa modes 1280x800x32 and 1920x1080x32 work for me, but only tested so far with VMWare and drawterm. Hm, does it not render at all then at 1920x1080x32? > JS support of opossum becomes much better... Awesome! Yeah quite some changes have happened on the JS side, really experimental AJAX support is also there. (On golang.org e.g. it's possible to run the example) Although right now I'm thinking to put the JS side into a separate process or even fs. That would reduce command line flags and all the messiness of js (support) itself. Apart from that a lot of issues about flickering (scrolling, loading text) and font sizing had been improved. Greetings, Philip ‐‐‐ Original Message ‐‐‐ Am Sonntag, 18 April 2021 06:05 schrieb : > I forgot to write that opossum-master runs successfull partially. > 'Partially' means the color is a little bit wrong, and I cannot use vesa mode > on 1920x1080x32, can do just under 1280x1024, and now using it > as 1024x768x32(sigh). > > JS support of opossum becomes much better... > > Kenji > > > --- > > 9fans: 9fans > Permalink: > https://9fans.topicbox.com/groups/9fans/T75ee4ccd407669dd-M065cb7408d643eb1ec0c5aea > Delivery options: https://9fans.topicbox.com/groups/9fans/subscription -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T75ee4ccd407669dd-Mc5a0258f7a1ab7d69f7c0597 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] netsurf or opossum
> > One big disadvantage is not having 'colspan'... > > Nice, now it has this, and do resizing of the window! True! At least the colspan is gracefully ignored, but probably it's really not that important :D Philip -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9a725c37f61954a8-Mbe2264f63687cbdc84fd6c2e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] netsurf or opossum
Although I guess generally it's good to have more than one Browser available. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9a725c37f61954a8-Mfe40f44f07f618e8e041c150 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] netsurf or opossum
That was unexpected, but it should be much better now! Now the character set hint is actually used ‐‐‐ Original Message ‐‐‐ Am Freitag, 23 April 2021 06:37 schrieb : > Please look at http://google.co.jp > > We see many 'NULL' on this page. > > Kenji > > > - > > 9fans: 9fans > Permalink: > https://9fans.topicbox.com/groups/9fans/T9a725c37f61954a8-M26405485fc05d412397ae633 > Delivery options: https://9fans.topicbox.com/groups/9fans/subscription -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9a725c37f61954a8-Me661195a090dd94d77e2ea9e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] netsurf or opossum
Awesome, no problem! > There is still 'NUL' character when 漢字 and ( or ), hankaku moji, are mixed: like > 例(日本語) ==>例NUL日本語NUL I wonder what that could be. So with the current version (910bfe from yesterday) it can work if the input is UTF-8: http://psilva.sdf.org/ja.html Do you maybe have a link with an example? Philip > Yes, now we can see right Japanese text! > Very quick fix, thanks. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9a725c37f61954a8-M451400dca342486b2cec37f1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --- Begin Message --- That was unexpected, but it should be much better now! Now the character set hint is actually used ‐‐‐ Original Message ‐‐‐ Am Freitag, 23 April 2021 06:37 schrieb : > Please look at http://google.co.jp > > We see many 'NULL' on this page. > > Kenji > > > - > > 9fans: 9fans > Permalink: > https://9fans.topicbox.com/groups/9fans/T9a725c37f61954a8-M26405485fc05d412397ae633 > Delivery options: https://9fans.topicbox.com/groups/9fans/subscription -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9a725c37f61954a8-Me661195a090dd94d77e2ea9e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --- End Message ---
Re: [9fans] netsurf or opossum
Hm ok, that's rather tricky to reproduce. (Also unfortunately I don't have a running 9legacy system) One thing I noticed though that for instance on https://ja.wikipedia.org the parentheses are usually fullwidth parentheses and on 9front rendered to the UTF8 face :-). I added a commit which maps these and other characters to their canonical widths. That's really a quick fix but it seems to improve things, maybe also there. It could also be solved font-wise, at some point I definitely want to write a function that checks which fonts are available. Philip -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9a725c37f61954a8-M4f7bb0fa486c25a34386f8b0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] netsurf or opossum
Hi!
Here's a patch for most of the fullwidth glyphs in lucidasans and vga! The
subfonts are already used in each font file. I guess one way to quickly test
would be:
hget https://ja.wikipedia.org | htmlfmt > /tmp/wp
for (font in /lib/font/bit/lucidasans/unicode.*.font
/lib/font/bit/vga/unicode.font) {
acme /tmp/wp
}
Probably a similar patch could also easily be created for the bold and italic
versions, but that's too much work for now :)
Philip
diff -r 859a4e61471b lib/font/bit/lucidasans/unicode.10.font
--- a/lib/font/bit/lucidasans/unicode.10.font Mon May 03 21:04:39 2021 +0200
+++ b/lib/font/bit/lucidasans/unicode.10.font Mon May 03 22:35:32 2021 +0200
@@ -55,6 +55,7 @@
0x9a01 0x9bf5 ../shinonome/k16.9a01
0x9c04 0x9dfd ../shinonome/k16.9c04
0x9e1a 0x9fa0 ../shinonome/k16.9e1a
+0xff01 0xffe5 ../shinonome/k16.ff01
0xfb1e 0xfb1e ../lucida/Althebrew.9.0
0xfff9 0x ../dejavu/dejavu.16.fff9
0xfb00 0xfc00 ../dejavu/dejavu.16.fb00
diff -r 859a4e61471b lib/font/bit/lucidasans/unicode.13.font
--- a/lib/font/bit/lucidasans/unicode.13.font Mon May 03 21:04:39 2021 +0200
+++ b/lib/font/bit/lucidasans/unicode.13.font Mon May 03 22:35:32 2021 +0200
@@ -56,3 +56,4 @@
0x9c00 0x9dff ../jis/jis9c00.24
0x9e00 0x9fff ../jis/jis9e00.24
0xfb1e 0xfb1e ../lucida/Althebrew.12.0
+0xfee0 0xff5e lsr.24
diff -r 859a4e61471b lib/font/bit/lucidasans/unicode.6.font
--- a/lib/font/bit/lucidasans/unicode.6.fontMon May 03 21:04:39 2021 +0200
+++ b/lib/font/bit/lucidasans/unicode.6.fontMon May 03 22:35:32 2021 +0200
@@ -56,6 +56,7 @@
0x9a01 0x9bf5 ../shinonome/k12.9a01
0x9c04 0x9dfd ../shinonome/k12.9c04
0x9e1a 0x9fa0 ../shinonome/k12.9e1a
+0xff01 0xffe5 ../shinonome/k12.ff01
0xfb00 0xfbff ../fixed/6x12.FB00
0xfe00 0xfeff ../fixed/6x12.FE00
0xff00 0x ../fixed/6x12.FF00
diff -r 859a4e61471b lib/font/bit/lucidasans/unicode.7.font
--- a/lib/font/bit/lucidasans/unicode.7.fontMon May 03 21:04:39 2021 +0200
+++ b/lib/font/bit/lucidasans/unicode.7.fontMon May 03 22:35:32 2021 +0200
@@ -59,6 +59,7 @@
0x9a01 0x9bf5 ../shinonome/k12.9a01
0x9c04 0x9dfd ../shinonome/k12.9c04
0x9e1a 0x9fa0 ../shinonome/k12.9e1a
+0xff01 0xffe5 ../shinonome/k12.ff01
0xfb00 0xfbff ../fixed/7x14.FB00
0xff00 0x ../fixed/7x14.FF00
0x0600 0x06ff ../fixed/9x15.0600
diff -r 859a4e61471b lib/font/bit/lucidasans/unicode.8.font
--- a/lib/font/bit/lucidasans/unicode.8.fontMon May 03 21:04:39 2021 +0200
+++ b/lib/font/bit/lucidasans/unicode.8.fontMon May 03 22:35:32 2021 +0200
@@ -66,6 +66,7 @@
0x9a01 0x9bf5 ../shinonome/k14.9a01
0x9c04 0x9dfd ../shinonome/k14.9c04
0x9e1a 0x9fa0 ../shinonome/k14.9e1a
+0xff01 0xffe5 ../shinonome/k14.ff01
0xfb00 0xfbff ../fixed/9x18.FB00
0xfe00 0xfeff ../fixed/9x18.FE00
0xff00 0x ../fixed/9x18.FF00
diff -r 859a4e61471b lib/font/bit/vga/unicode.font
--- a/lib/font/bit/vga/unicode.font Mon May 03 21:04:39 2021 +0200
+++ b/lib/font/bit/vga/unicode.font Mon May 03 22:35:32 2021 +0200
@@ -191,6 +191,7 @@
0x9a01 0x9bf5 ../shinonome/k12.9a01
0x9c04 0x9dfd ../shinonome/k12.9c04
0x9e1a 0x9fa0 ../shinonome/k12.9e1a
+0xff01 0xffe5 ../shinonome/k12.ff01
0x0e00 0x0eff ../fixed/7x14.0E00
0x1600 0x16ff ../fixed/7x14.1600
0x2400 0x24ff ../fixed/7x14.2400
‐‐‐ Original Message ‐‐‐
Am Montag, 26 April 2021 21:29 schrieb :
> Yes, that seems like a font issue, and should be fixed there.
> I'll gladly commit patches that fix missing glyphs.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T9a725c37f61954a8-M868b7e06206f0a22d9fdd868
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] netsurf or opossum
The figures turn out to be quite practical though! :) Non-utf8 Encoding for most forms should work now, although some corner-cases for POST are still missing. Probably the fonts could be copied over or you can look for fonts that include subfonts covering the fullwidth ranges 0xff01-0xffe5. By the way, the fonts are configurable now, so the $font env variable is parsed, e.g. it's possible to start with: font=/lib/font/bit/pelm/unicode.9.font go run . All unicode.###.font files are then used for scaling, unfortunately anti aliased fonts don't work well yet. Also I found ttf2subf and the fontsel tool quite practical: http://9front.org/extra/ttf2subf.tgz http://shithub.us/sigrid/fontsel/HEAD/info.html https://plan9.io/wiki/plan9/fonts/index.html Philip > You see 日本語 string changed to other unknown word. > > PS: this is also a test of 9legacy's upas to attach figures☺ -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9a725c37f61954a8-Mbb6f7d85b8d0afb3b15d51c9 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] p9f mention of 9front
I wonder if this could be copied from how plan9port behaves on macOS for instance. Using a single tap and then toggling/chording using alt and command keys. Maybe on a multi-touch input the distance of the 2nd and 3rd finger could help to identify which modifier/button it translates to. ‐‐‐ Original Message ‐‐‐ Frank D. Engel, Jr. schrieb am Donnerstag, 24. Juni 2021 um 10:24: > The rio environment would need to identify if you were using finger 1, 2 > > or 3 to tap on something so it would know if it was to move or resize > -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Ma226d19a1eea70cb2dc82b62 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] sam and samterm in Go
Hi! Actually there is a separate fork of 9fans.net/go that also runs on Plan 9 and uses the /dev/draw there! Here it's now all merged together: https://github.com/psilva261/go Philip > How I can use those sam/samterm on plan9? > > I compiled those, and run sam as > > teerm% sam > > samterm: drawinit: drawfcall.New: exec: "devdraw": executable file not found > in $path > > Kenji -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T15127d7ddd5c7310-M1f413083a9110f16fc3a17a0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Drawterm GPU (was: Software philosophy)
Vulkan (at least its promises) looks interesting though. As far as I understand it's more like a Meta API, really low-level and it claims to be very portable. But as mentioned before, the Hello Worlds are really long, apparently it's rather >1000 lines instead of "just" >100 for OpenGL. On the other hand for driver development it might be less effort but seems to have its own pitfalls. (This is the only article I found about the driver aspect of it: https://lwn.net/Articles/702021/) > > But for serious 3d AAA stuff we'd have to consider: Lumen is for next-gen > > > > GPUs and Nanite for newer GPUs. We'll never reach their quality in > > > > realtime if we don't use the GPU features (built-in rasterizer, ...) to > > > > have enough free power for crazy software calculation. > > By the time any code is written, next-gen GPUs will be > > previous-gen GPUs. > > General compute is what any hardware you buy a few years > > from now will be doing -- and it's far more intersting > > in terms of what capabilities it allows. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Mc570eb4778bbb92d838c9b3c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] porting projects...
Not sure if it's wasted/duplicate effort but I had been interested in porting QuickJS (it has ES 2020 support) Eventually I stopped doing this since there is Duktape (within Netsurf) and Goja now support some of the most common ES6 features. Also my C knowledge/porting experience is quite limited. Philip -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td6b6b3e98268ecde-M067fe527d54128af356daf61 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] porting projects...
Awesome, I'll try that! Yeah I realize there is also this Bignum support, that's probably not a very common use case. On Saturday, September 4th, 2021 at 17:24, Sigrid Solveig Haflínudóttir wrote: > https://git.sr.ht/~ft/quickjs > > I have not finished it, ofc, but it successfully ran a few scripts on > > 9front amd64. Quickjs uses uint128_t which makes everything much more > > complicated. I don't know if kencc should support 128 bit just to > > make JS work. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td6b6b3e98268ecde-M68c871b8c7a41fd5adcf5c39 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Re: 9legacy rpi4 usb installation + 9front libsec + ...
An additional link: http://shithub.us/ph/misc/f54501c2592bd7cee283a243391d07f2dd131373/9legacy/f.html That's a bit improvised. I might still organize this a bit better or move this into garden eventually. (Thanks for letting me archive this though) Philip ‐‐‐ Original Message ‐‐‐ On Monday, November 22nd, 2021 at 23:10, adr wrote: > this). Two people contacted me telling me they were going to archive > > it, Vester "Vic" Thacker at > > https://tip9ug.jp/who/adr/ > > and Philip Silva. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T585a46c9a2003432-Mf9d3585de2dda1ebbcfef92e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Re: 9legacy rpi4 usb installation + 9front libsec + ...
Ah ok, I think it should now be self-contained: http://shithub.us/ph/misc/HEAD/9legacy/f.html Included also the pi4rc and the bootusb.rc! (Not really sure about the sam_label_command_riosnarf.diff, probably I'll take a look another time and at least add something to the README) Greetings, Philip ‐‐‐ Original Message ‐‐‐ On Tuesday, November 23rd, 2021 at 00:56, adr wrote: > On Mon, 22 Nov 2021, adr wrote: > > > > http://shithub.us/ph/misc/f54501c2592bd7cee283a243391d07f2dd131373/9legacy/f.html > > Also better update > http://adr.freeshell.org/plan9/patches/sam_label_command_riosnarf.diff, it > had a bug. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T585a46c9a2003432-M030d920427055be0fdb77563 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Re: 9legacy rpi4 usb installation + 9front libsec + ...
I see, now it's actually updated :-) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T585a46c9a2003432-M7c816af7c0c36e4032e44391 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Sorry, I'm late (Christmas, New Year)
Hi, also from me merry Christmas and happy New Year! I think the Plan 9 Bootcamp from smj which happened also in 2021 is really great. That makes it much easier to really get started doing interesting things despite 9front already being surprisingly well documented and easy to install. Although I eventually managed to setup 9pi and 9legacy on qemu thanks to the Plan 9 Desktop Guide. Also everything around Shithub is really great and that Go has stayed compatible with 9front. Hopefully the systems will keep having a common subset since this makes copying code much easier! Greetings, Philip -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8425cdee7071f9dc-M59a5fa0231ef9c498afc18fd Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] suggestion : new service targets for plan9
Also of course it depends on what needs to be rendered. I didn't deep-dive yet into the internals of it, but isn't it that when combining the images at the end, that transfer of the initial images with lots of data basically happens only once? It seems to me devdraw can be quite performant on certain use cases. (UIs with basic shapes) But true, having access to the framebuffer should offer more options. Also I wonder what kind of functions it should be providing. (And if devdraw couldn't be just made faster) > What I suggest is a lower level interface to use the framebuffer directly and > I think devdraw (memdraw, memlayer) is too high level and rio oriented. ... > Also the transfer of images in this way is expensive (regarding time) a > screen image is at least copied two times. So by defining a lower level we > could improve the performance of rendering by a factor of two. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M3f8fff74c67b09c5e2cde53f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Pipes staying after sending note
Hello,
I'm trying to understand how pipes work when terminating a forked process. It
seems when sending kill to the forked process, connected pipes don't always
break. At least a subsequent write might work. Is it possible to make it
reliably fail anyway or is it necessary to close the file descriptors from the
calling process?
#include
#include
#include
void sendnote(int cpid) {
int fd;
char fn[20], buf[20];
sprintf(fn, "/proc/%d/note", cpid);
if ((fd = open(fn, OWRITE)) <= 0) {
printf("open %s\n", fd);
}
if (write(fd, "kill", 5) == 0) {
printf("write error\n");
}
close(fd);
return;
}
int main() {
int cpid, infd[2], outfd[2], n;
char outbuf[20], inbuf[20];
char *args[] = {"/bin/cat", NULL};
pipe(infd);
pipe(outfd);
if ((cpid = fork()) != 0) {
close(infd[1]);
close(outfd[1]);
n = write(infd[0], "test", 4);
printf("check process: wrote %d bytes\n", n);
sendnote(cpid);
// close(infd[0]); // <--- uncomment to make write fail
// close(outfd[0]);
n = write(infd[0], "test2", 5);
printf("write: wrote %d bytes\n", n);
n = read(outfd[0], outbuf, 20);
printf("outbuf=%s (n=%d)\n", outbuf, n);
wait();
return 0;
}
dup(infd[1], 0);
close(infd[0]);
close(infd[1]);
dup(outfd[1], 1);
close(outfd[0]);
close(outfd[1]);
exec("/bin/cat", args);
return 0;
}
Will output:
check process: wrote 4 bytes
write: wrote 5 bytes
outbuf=test (n=4)
6.out 82435: main
Closing the FDs after sending the note:
check process: wrote 4 bytes
write: wrote -1 bytes
outbuf= (n=-1)
6.out 82423: main
On the other hand instead of closing just adding sleep(1) after sendnote()
produces:
check process: wrote 4 bytes
6.out 82595: sys: write on closed pipe pc=0x202603
(That's more or less also reproducing a part of Go's os/exec TestContextCancel)
Greetings, Philip
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T3392001a02ee7ec8-Ma261d9fb098775daa526c6b3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] RPi in QEMU
Hi, I've only tried qemu with 9front and this got me to a console (the files in dos/ are from the image): EXTRA_ARGS='user=glenda nobootprompt=local!/dev/sdM0/fs virtio nousbrc=' qemu-system-aarch64 -M raspi3b -dtb dos/bcm2711-rpi-4-b.dtb -kernel dos/9PI3 -append "console='1 b9600' core_freq=250 arm_64bit=1 gpu_mem=16 enable_uart=1 boot_delay=1 $EXTRA_ARGS" -drive file=9front.img,if=sd,format=raw -serial mon:stdio It's awfully slow though but maybe it's possible to run fast with KVM. Also I had been trying https://github.com/0xMirasio/qemu-patch-raspberry4.git but I think it also works with an unpatched qemu. Philip -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T5da5467097e4eab2-M7e01ab465d585393c0cf2f6b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] RPi in QEMU
Hosting options are quite limited though, there's Hetzner and actually also Arm Virtual Hardware but I couldn't get 9front running there. And at least on real hardware running 32 bit on aarch64 seems to work. Also on macOS qemu there's hardware acceleration. I've tried that as well but I think I ran into another problem there. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T5da5467097e4eab2-Me82a3a9b67690664ab9ba539 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] can i stll golang on plan9?
Hi! This repository can be cross-built to arm64:
https://github.com/psilva261/go-arm64.plan9.git
It's a dev version of 1.22 at the moment (I need to update this actually)
On Friday, January 24th, 2025 at 5:04 PM, Bakul Shah via 9fans
<9fans@9fans.net> wrote:
> I see
> [go1.23.5.plan9-{386,amd64,arm}.tar.gz](https://go.dev/dl/go1.23.5.plan9-arm.tar.gz)
> on go.dev/dl/. Presumably you can cross-build for arm64?
> See also this long thread: https://github.com/golang/go/issues/57540
>
>> On Jan 24, 2025, at 12:23 AM, Steve Simon wrote:
>>
>> hi,
>>
>> does the go compiler and runtime work on 9front, specificly, does it work on
>> the raspberry pi?
>>
>> thanks,
>>
>> -Steve
>
> [9fans](https://9fans.topicbox.com/latest) / 9fans / see
> [discussions](https://9fans.topicbox.com/groups/9fans) +
> [participants](https://9fans.topicbox.com/groups/9fans/members) + [delivery
> options](https://9fans.topicbox.com/groups/9fans/subscription)
> [Permalink](https://9fans.topicbox.com/groups/9fans/T6fe601aa30dd8c2b-M2467b55337d1cf5e7d9dd704)
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T6fe601aa30dd8c2b-M0b0164fdee747bafbaf82fe5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
