Re: [9fans] mk results in rc: suicide:
The useful hints will be in lstk() (does
the stack look sane), as well as in the
disassembly of the code (asm(Readdir), casm())
It seems unlikely that 'f' is out of
bounds, given the bounds check above,
which makes me suspect a corrupted binary.
On Sun, 7 Jul 2024 17:36:35 +0200
Marco Feichtinger wrote:
> Error during compiling:
> rc 718: suicide: sys: trap: fault read addr=0x965708 pc=0xb5d9
> mk: 8c -FTVw mtrr.c : exit status=rc 718: sys: trap: fault read
> addr=0x965708 pc=0xb5d9
>
> acid:
> term% acid 718
> /proc/718/text:386 plan 9 executable
> /sys/lib/acid/port
> /sys/lib/acid/386
> acid: src(0xb5d9)
> /sys/src/cmd/rc/plan9.c:476
> 471int n;
> 472
> 473if(f<0 || f>=NFD)
> 474return 0;
> 475Again:
> >476if(dir[f].i==dir[f].n){ /* read */
> 477free(dir[f].dbuf);
> 478dir[f].dbuf = 0;
> 479n = dirread(f, [f].dbuf);
> 480if(n>0){
> 481if(onlydirs){
> acid: regs()
> PC 0xb5d9 Readdir+0x2d /sys/src/cmd/rc/plan9.c:476
> SP 0xdfffeea3 ECODE 0x0004 EFLAG 0x00010286
> CS 0x0023 DS0x001b SS 0x001b
> GS 0x001b FS0x001b ES 0x001b
> TRAP0x000e page fault
> AX 0xdfffef00 BX 0x00965700 CX 0x0214 DX 0x00040b20
> DI 0x00016ca7 SI 0x00155720 BP 0x000176c8
> acid:
>
> I didn't get any wiser.
>
> -marco
>
--
Ori Bernstein
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T68f44cf88ca61ff3-Md46471297fafa3051bd167f4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Mon, 13 May 2024 11:56:20 -0400 "ibrahim via 9fans" <9fans@9fans.net> wrote: > I'm wondering why you don't adjust it so that 9front can also be run there. Because 9vx is a hacky dead end; it fundamentally only runs (and can only run) on 32-bit x86. It works because of a quirk of 32-bit x86 addressing. Linux distros are wanting to drop support for running 32 bit binaries (Ubuntu tried in 2019, others have tried on and off). Macs no longer ship x86 processors, and even the ones that have x86 cpus dropped support for 32-bit binaries 5 years ago. I have no idea what windows is up to. Basically, qemu/drawterm works better in more or less every way. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M5d593a074dd95a16887f6a83 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Mon, 13 May 2024 06:52:37 -0400, "ibrahim via 9fans" <9fans@9fans.net> wrote: > > This was an example and I didn't find the original licenses from freetype in > the folder or in the code. Perhaps they got lost while porting this code to > 9front. Indeed, it would be strange to find them, given that we don't ship freetype. -- Ori Bernstein -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Me2f7348f05a060950815e38e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] VCS on Plan9
On Thu, 18 Apr 2024 15:54:07 + "certanan via 9fans" <9fans@9fans.net> wrote: > Hi, > > is there any more "organic/natural" way to do source control on today's Plan9 > (9front specifically), other than Ori's Git? on today's plan 9? no. > > In other words, how (if at all) did people at Bell Labs and the community > alike originally manage their contributions in a way that would allow them to > create patches without much hassle? on labs plan 9: https://9p.io/magic/man2html/1/patch I dont think anyone is submitting patches with this any more. > > Was it as simple as backing a source tree up, making some changes, and then > comparing the two? Venti? Replica? > > tom -- Ori Bernstein -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M59f6a60a62da218a9404b228 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Last Call: IWP9 Shirts + Registration
While we're happy to take late registrations, we need to put out the t-shirt order. I'll be sending that out on April 1st, so if you haven't registered before then, your shirt will not be ordered. For those that have ordered, there should be an email requesting shirt size info that you need to respond to. -- Ori Bernstein -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T05224b13e5a0cf96-M94d192f2eec9c484f2a6545b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] IWP9 10th Edition
This probably should have been mentioned earlier -- while it'd be better to have presentations in person, we'd be happy to take remote presentations too. On Tue, 9 Jan 2024 11:53:04 -0800, Skip Tavakkolian wrote: > Hi everyone, > > Paper submission deadline is coming up fast. We understand that some > may be hesitant to submit papers or WIPs for various reasons. If you > have any questions or concerns that are holding you back, please > contact us. We are also planning to provide a help session (Google > Meet) to answer questions and give feedback. You can use the > addresses provided for paper and WIP submissions at > https://www.iwp9.org to ask questions or get information about the > help session. > > Thanks, > -Skip > > > On Wed, Nov 15, 2023 at 2:03 PM Brian L. Stuart > wrote: > > > > The Plan 9 Foundation and the Workshop Program Committee are > > pleased to invite participation in the 10th International > > Workshop on Plan 9. This event will take place April 12-14, > > 2024 on the campus of Drexel University in Philadelphia. We > > invite submission of papers, works in progress (WiPs), and > > workshop proposals. Everyone interested in Plan 9 and > > related technologies is encouraged to attend. > > > > To assist in your planning, a few key dates include: > > January 30, 2024: Submission Deadline > > March 10, 2024: Preferred Registration Deadline (later > > registrations will be accepted) > > April 12-14, 2024: The Workshop > > We will be following up with details on hotels. > > > > For complete details, see the Call for Papers at: > > > > https://www.cs.drexel.edu/~bls96/iwp9_2024_cfp.pdf > > > > A special note on scheduling: the workshop falls on the > > weekend following the upcoming total solar eclipse on April > > 8, 2024. Although we will not have totality in Philadelphia, > > the path of totality is reachable from Philadelphia in less > > than a day's driving time. So take advantage of the > > scheduling to experience both one of nature's most amazing > > events and discussions of computing's most amazing operating > > system. > > > > Brian L. Stuart > > IWP9 Program Committee -- Ori Bernstein -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tfe83e4e703ab52ec-Mb972698f1c47a1410e1876ae Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] programs from UNI*x
On Fri, 30 Jun 2023 11:26:09 +0100, Conor Williams wrote: > https://conorwilliams.in/nh4.png > > now looking in win?? /c early friday yay lie in 2morow > sysupdate; it's been added as of commit 5664fb3540ae0dccec628720574520122193ab1b, on Fri Mar 17 16:24:30 -0400 2023 -- Ori Bernstein -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e60a159b1280462-M61eca930eceb2f2e8fc65899 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] factotum vs. SASL+TLS+applications
> The following is all hypothetical. I'm curious about how people > think auth(2)/factotum(4) could be adapted to support the use > case ... > > factotum was intended to handle the authentication dance on behalf > of network apps. But in the case of things like IMAP, it really > just stores the client's login/password, and provides a bit of > helper glue for CRAM-MD5. Similarly for ftpfs. > > I'm curious why upasfs and ftpfs are outliers in only using factotum > as a credential store, but leaving the actual authentication protocol > dance in the clients/servers. The "Security" paper (/sys/doc/auth) > strongly hints that these parts of the application protocols were > meant to be outsourced to factotum. Section 2.2 in particular > argues that the auth modules should be implemented once in factotum, > for consumption by the rest of the system. Probably simple expediency. > > > To require a specific SASL mechanism, add "sasl=scram-md5" (using > "sasl=*" as a default if you need to fall back for some reason). This all sounds fairly reasonable. I think that patches to this effect would be worth integrating. > Of course all of this needs to be glued into auth(2) in a way that > doesn't destroy the existing API. But it does need to handle > factotum replacing the underlying connection to the client/server > with one that has been pushtls()ed by factotum itself. I'm not sure how factotum can have this action at a distance. I think the pushtls is stuck in the client itself -- though, the auth code can probably return the parameters needed for this. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8154f8e7b95f1a8c-M16c4ed9e42454938bd4e69b7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Is the vanilla Plan 9 still alive?
On Sun, 24 Nov 2019 08:34:32 +0200, Lucio De Re wrote: > We just got a mouthful from sl and you about the lack of explanation > for the state of the various plan 9 "distributions". It all smacks of > expecting Da Vinci to update the Mona Lisa because somebody would > prefer a high-rise landscape in the background and because someone > actually did photoshop the Mona Lisa in that guise, but was not > accepted as the most significant contributor to the painting. I'm not sure that analogy serves the purpose intended. The Mona Lisa is something sitting in a museum for people to gawk at a bit before getting on with their day to day business, using tools that they either adapt to their needs, or replace with ones that are already suitable. -- Ori Bernstein -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf27e6479d8812712-M984d5d8d61bf4501acf6d6b0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Is the vanilla Plan 9 still alive?
On Sat, 23 Nov 2019 08:24:41 -0600, Steven Stallion wrote: Against my better judgement... On Sat, 23 Nov 2019 08:24:41 -0600, Steven Stallion wrote: > On Sat, Nov 23, 2019 at 3:30 AM Richard Miller <9f...@hamnavoe.com> wrote: > > Grow up. > > Indeed. It's interesting that folks from 9front like to tout their > development as "open" using tools that others in the community have > developed in addition to their own. To wit, you seem to have gotten > along quite nicely using the porting work I did for Mercurial in 2012. Yes, and thank you. I mean that. You put your code in the open, and people that found it useful were able to use it. > The Plan 9 community is certainly fragmented, but there are still a > number of people that are willing to share their knowledge and work > with others and it benefits no one to cast aspersions. It's frustrating. I *want* to see a healthy, active Labs distribution. >From my viewpoint, fragmentation doesn't capture the nature of the difficulty. The problem is that the fragments are invisible. The most official looking site for vanilla plan9 is 9p.io. It doesn't show any sign of activity since 2015. The wiki not only fails to point to a more up to date location, it confuses the issue by exclusively pointing at dead links. 9legacy exists. It doesn't bill itself as living continuation of Plan 9. It claims it's a patch set for the last image to come out of the moldering corpse of Bell Labs. Even there, '9fs sources' tries to connect to the long-gone sources.cs.bell-labs.com. There's code scattered on contrib, but as for who has the most up to date/maintained/functioinal version of something -- it's hearsay, and usually, I haven't heard anyone say. There's the plan9-contrib github repository, but the last commit on that was over a year ago, and until recently, there was no way to use it *from* plan 9 -- now, lufia has ported git, and I wrote git9. Lufia's patches seem to be stalled in review. There are contrib directories, but projects are haphazardly thrown in, often duplicated them, with no indication of what's working, up to date, or maintained. Code may exist, but... where? I've been around for a while and I would have trouble finding the bits needed for a day-to-day usable system outside of the 9front world. God have mercy on someone trying to use the system seriously for the first time. -- Ori Bernstein -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf27e6479d8812712-Mb9b516149f01370f96ffb6b8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] aux/timesync -n doesn't work
On Tue, 10 Sep 2019 17:20:49 +0300, __
wrote:
> aux/timesync doesnt work in raspberry pi 2. How to fix this problem ?
Can you define what doesn't work?
--
Ori Bernstein
Re: [9fans] Git/fs: Possibly Usable
On Mon, 5 Aug 2019 11:43:33 -0700, Skip Tavakkolian
wrote:
> is this an equivalent fix for 9legacy env? (i'm guessing the answer is no)
>
> % diff clone /bin/git/clone
> 75c75
> < for(f in `$nl{walk -f $tree | sed 's@^'$tree'/*@@'}){
> ---
> > for(f in `{ifs=$nl walk -f $tree | sed 's@^'$tree'/*@@'}){
>
You can also set ifs outside of the `{...}.
However, I think it's worth importing the 9atom change into 9legacy
rc. It's an elegant solution.
--
Ori Bernstein
Re: [9fans] Git/fs: Possibly Usable
On Sun, 21 Jul 2019 16:06:54 -0500 clue...@tonymendoza.us wrote: > Thanks Ori! > > I pulled it down today and started using it against a few GitHub repos I > have. For those who are thinking about using it, it only uses 'git' and > 'git+ssh' style URLs, but they work so far without incident. > > git/clone git+ssh://g...@github.com:tmendoza/9front-user > > Once I got keys generated and pushed to github.com, worked just fine. My > updates show up as expected. Good to hear! -- Ori Bernstein
Re: [9fans] Git/fs: Possibly Usable
On Mon, 1 Apr 2019 21:41:09 -0700
o...@eigenstate.org wrote:
> It was mentioned on this list a short while ago. Now, it's
> more or less at the point where it works for me. Expect
> many bugs and problems, and many more missing tools, but
> "the rest is just scripting".
An update: I'm now using this git implementation on a daily
basis. It's hosting its own development now, and tons of
bugs have been fixed.
All commits in the git mirror here were made with git9 on 9front:
https://github.com/oridb/git9
I'm also keeping the old mirror in hg alive:
https://bitbucket.org/oridb/git9
There's one incompatibility that I'm aware of with 9legacy, where
I use `$split{...} syntax in rc to make files with spaces work
cleanly. I don't think 9legacy imported that patch from 9atom.
The remaining missing bits, in my mind:
- UI polish; There's some thought needed about how
the exposed functionality should work.
- Patch import/export: probably git/diff -[pa] for
generating or importing `git format-patch` compatible
style diff.
- Rebase-like functionality would be nice.
- (Low priority, probably won't do it myself, but I'd
take a patch): HTTP protocol. Most places (including
github) serve up git protocol URLS, in the form
git://github.com/user/repo
--
Ori Bernstein
Re: [9fans] POSIX shared memory (shm_open)
On Wed, 24 Apr 2019 18:22:35 +0300, Lassi Kortela wrote: > Hello, > > Can the POSIX shared memory API be emulated on Plan 9 with reasonable > effort? I didn't find any mention of 'shm_open' in Plan 9 source. It's almost certainly an intentional omission. What problem are you trying to solve with it? > To recap, the API works as follows: > > - shm_open(path) to open or create an shm object, get a file descriptor > - shm_unlink(path) to remove the shm object from the path namespace > - ftruncate(fd) to actually allocate n bytes for the shm object > - fstat(fd) returns the size of the object in the st_size field > - mmap(fd) to get a pointer to use the shared memory With enough effort, it's certainly possible, to do what you want, but I predict it will either fit poorly into plan 9, or it will perform poorly. It'sl likely to end up in a state where it's a combination of both. Why will it fit poorly into plan 9? Because plan 9 is a distributed system, and it's common practice to run programs on different systems sharing the same namespace -- essentially, assembling a computing environment from multiple computers. In that kind of environment, programs aren't even aware of which machines resources they're accessing: it's just transparent. So, when you put a mutex into shared memory, for example, how is it supposed to work when the shared memory is coming from another machine? Assuming that you have an approach for that in mind (including, possibly, ignoring it and making porgrams break), the plan 9 memory management system is designed with the assumption that only a small number of contiguous, disjoint regions (segments) will be attached to a program. Typical programs have 4. If you still want to implement it, start by reading the code for segattach. You can proably put together a hacky version that breaks the distributed parts of the system and scales poorly with the number of shm regions fairly quickly. Making it good is harder. Either way, if you decide to experiment, I'd be interested in seeing what you write. -- Ori Bernstein
Re: [9fans] UI design | enhancements.
On Mon, 15 Apr 2019 16:59:12 -0400 Marshall Conover wrote: > For example, I feel super squished on a single screen, but I've come to > dislike the awkwardness of switching between multiple 'workspaces' or > working with tiling wms. So I'm playing around with rio at the moment to > see if adding a 'panning' effect, where you treat the desktop as an > infinitely-scrollable table and allow the user to 'pan' around the table, > could be a natural approach to feeling less squished. It may end up being > even more awkward and painful, but it may also end up being something I'm > left wanting for in modern DEs - that could be an attraction to 9. >From man 3 vga: panning mode Depending on whether mode is on or off, enable or dis- able panning in a virtual screen. If panning is on and the screen's size is larger than its actualsize, the displayed portion of the screen will pan to follow the mouse. Setting the panning mode after the first attach of the #i driver has no effect. -- Ori Bernstein
Re: [9fans] Git/fs: Possibly Usable
On Wed, 3 Apr 2019 13:23:08 -0700 Ori Bernstein wrote: > - I can remove the libavl usage, possibly replacing with > the objset implementation I already have. Did this one. Turned out to save a couple of lines, in the end. -- Ori Bernstein
Re: [9fans] Git/fs: Possibly Usable
On Wed, 3 Apr 2019 11:29:30 -0700 Skip Tavakkolian wrote: > Hi, > > The avl library doesn't match up to 9legacy version. Any ideas? Looking at a few options. I can just say "well, patch it", but it'd be nice to see the various plan9s playing better with each other. There are a few options. The easy ones: - I can bundle the 9front libavl in git9. - I can remove the libavl usage, possibly replacing with the objset implementation I already have. The harder ones: - 9front can provide compatibility with 9legacy libavl - 9legacy can adopt the 9front libavl API. The first two are easy. The other two involve herding cats, but would make it possible for more code to be shared. Given how few people are actually writing code on plan 9, it would be nice to share what is there. Right now, I'm leaning towards the second option, because all I really use libavl for is a key-value lookup. > BTW, I think your notes on this message are a great start for a README. Already done. -- Ori Bernstein
Re: [9fans] Git/fs: Possibly Usable
On Wed, 03 Apr 2019 16:59:22 + Giacomo wrote: > On April 3, 2019 4:02:49 PM UTC, o...@eigenstate.org wrote: > >Don't particularly care. At some point I'd like to commit it to 9front, > >but I can relicense it then. > > > >Do you have a preference? > > Probably MIT or a BSD. > > But I can also live with any copyleft of your choice. > > > Giacomo > MIT it is, since it matches the 9front license. -- Ori Bernstein
Re: [9fans] any git client?
On Tue, 05 Feb 2019 11:42:48 +0100 Emery Hemingway wrote: > On Sunday, February 3, 2019 3:32:30 PM CET, Mayuresh Kathe wrote: > > is there a port of "libgit2" available? > > Libgit2 *is not* portable. They use mmap everywhere for I/O, which breaks > for 9P or NFS. > > https://github.com/libgit2/libgit2/blob/635693d3bc55770ec7a6640ba3f2f0ee434a6042/src/indexer.c#L597 > libgit2 has defines that allow it to work without mmap. It needs a bit of work to port to plan 9, but I did it in the past. https://bitbucket.org/oridb/libgit2/commits/all I'm not currently maintaining it. I'm not sure how much of it actually works. -- Ori Bernstein
Re: [9fans] any git client?
On Sun, 3 Feb 2019 13:19:34 -0600, Sean Hinchee wrote:
> There's Ori's git9 wip: https://bitbucket.org/oridb/git9
WIP is the key word. It's not usable (yet).
git/clone: basically works, but is missing a bit of code to update
branches.
git/fs: will serve up commits as an fs, but it's rather crashy.
git/commit: makes commits, really clunky.
git/push: started on an implementation, doesn't yet work.
Merging, branching, etc should be relatviely easy to do on top of
git/fs, but I haven't had time to take a look at them.
--
Ori Bernstein
Re: [9fans] zero copy & 9p (was Re: PDP11 (Was: Re: what heavy negativity!)
On Thu, 11 Oct 2018 13:43:00 -0700, Lyndon Nerenberg wrote: > Another case to ponder ... We're handling the incoming I/Q data > stream, but need to fan that out to many downstream consumers. If > we already read the data into a page, then flip it to the first > consumer, is there a benefit to adding a reference counter to that > read-only page and leaving the page live until the counter expires? > > Hiro clamours for benchmarks. I agree. Some basic searches I've > done don't show anyone trying this out with P9 (and publishing > their results). Anybody have hints/references to prior work? > > --lyndon > I don't believe anyone has done the work yet. I'd be interested to see what you come up with. -- Ori Bernstein
Re: [9fans] PDP11 (Was: Re: what heavy negativity!)
On Tue, 9 Oct 2018 10:50:08 -0700 Bakul Shah wrote: > Exactly! No point in being scared by labels! I am really > only talking about distilling plan9 further. At least as a > thought experiment. > > Isn’t it more fun to discuss this than all the “heavy > negativity”? :-) It's much better with patches. -- Ori Bernstein
Re: [9fans] rio : not completely rio-like : advice from packard!
On Wed, 3 Oct 2018 08:25:04 +0530, Mayuresh Kathe wrote: > hi, > > i just read that the rio in plan9port doesn't behave completely like the > rio in plan 9 because of problems inherent in x11/xorg. > > could someone who understands x11/xorg well enough to have worked on > developing or enhancing rio under plan9ports please communicate with > keith packard? he's the god of x, and should be able to advise on a > solution either directly or as a work-around. The issue is that there is no (well defined) way to hand off a window between different X programs, so they must open a new . The fix would involve patching every X program. Good luck. -- Ori Bernstein
Re: [9fans] 9front VMX
On Mon, 10 Sep 2018 18:57:29 +0100 Steve Simon wrote: > is there any graphics support? would it be usable to run a browser? dillo > talking to a framebuffer maybe? > > ever hopefull of getting modern browser support in plan9... > > -Steve Chrome and Firefox work, if you're willing to wait as the screen repaints. -- Ori Bernstein
Re: [9fans] Is Plan 9 C "Less Dangerous?"
On Wed, 5 Sep 2018 09:30:22 +1000, Tyga wrote: > Ha HA ! Good one ! > CPUs, such as Intel/AMD x64 > are vastly more complex so "optimising" C compilers are trying to make > something simple take advantage of something far more complex. Ironically, because of the complexity in the CPUs, many of the optimizations make less of a difference now -- they're essentially optimizing just in time compilers under the hood, so even terrible code will run acceptably quickly. -- Ori Bernstein
Re: [9fans] Plan 9's style(6) manual page
On Sat, 07 Apr 2018 19:00:37 +0300, 8hal...@airmail.cc wrote: > Just an amateur C programmer looking for answers. My main inspirations for > code style is K 2nd edition and I'm curious about the instructions in Plan > 9's style(6) manual page (for reference, > http://man.cat-v.org/plan_9/6/style). I've > tried to think about the motivations, but not everything is as clear as > it seems. The manpage explains the reasoning: Ultimately, the goal is to write code that fits in with the other code around it and the system as a whole. So, most of the answers to your questions are simply that someone had a preference early on. They wrote the code. If you want your code to fit in with theirs, this is how to do it. -- Ori Bernstein
Re: [9fans] Inferno on microcontrollers
On Tue, 2 Jan 2018 14:35:46 + Rui Carmo <rui.ca...@gmail.com> wrote: > > Perhaps because then you wouldn’t need those other boxes as much? I find the > notion of having a minimal self-sufficient environment (i.e., one with > creature comforts like a browser to read documentation) interesting - and > achievable on other operating systems. > > R. > Exactly. That's why I finally caved and ordered a new laptop, one that can run aux/vmx on 9front, and use a virtual machine with a browser without needing access to another machine. -- Ori Bernstein <o...@eigenstate.org>
Re: [9fans] p9p: 9 ls /dev
On Sat, 8 Apr 2017 15:21:47 +0900, arisawa <karis...@gmail.com> wrote: > but how to? > > unix doesn’t have something like fdreaddir(int fd). > my guess: russ unwillingly used a low level function such as > int getdirentries(int fd, char *buf, int nbytes, long *basep). > > readdirall() might be OK in regular usage. I don't use OSX regularly, although I do maintain the syscall layer for Myrddin on it. Getdirentries64 exists, and rudimentary testing doesn't show any difficulties with using it. -- Ori Bernstein
Re: [9fans] IPV6
On Sat, Apr 01, 2017 at 08:36:55PM +1100, Bruce Ellis wrote: > Does anyone know what IPV6 addresses like fec0:0:0:%1 mean and how to > make a real (plan9) IPV6 address from them. > > Regards. > > brucee The portion before the '%' is a plain old (link local) ipv6 address. The part after the '%' is a zone id. It's safe to ignore. Because link local addresses share prefixes, they may need to be told what interface to come out of. They can be ignored safely enough, or if you want you use an arbitrary string like 'fe80::%/net.alt' as the zone.
Re: [9fans] Porting Idris to 9front
On Sun, 15 Jan 2017 01:02:11 +0530, Ramakrishnan Muthukrishnan
<r...@rkrishnan.org> wrote:
> After reading your message, I tried compiling a simple program using the
> '-fviaC'. But it looks like, on newer GHC it is deprecated and is going
> to be removed soon.
Which may still be sufficient to produce a bootstrap binary for -fasm, if
you're willing to put in the effort to get a native port.
--
Ori Bernstein
Re: [9fans] Plan 9 5th Edition
Plan9 doesn't use make. It has a mkfile as well. On Thu, 17 Nov 2016 15:29:58 -0500, Chris McGee <newton...@gmail.com> wrote: > It doesn't build for me anymore. Fixing the make file seemed non trivial. > > Chris > > > On Nov 17, 2016, at 12:50 PM, Ori Bernstein <o...@eigenstate.org> wrote: > > > > https://bitbucket.org/oridb/libgit2 > > > > If someone wants to actually turn it into a git client, it at least builds > > (or used to). > > > >> On Thu, 17 Nov 2016 11:16:20 -0500, Dave MacFarlane <driu...@gmail.com> > >> wrote: > >> > >>> On Wed, Nov 16, 2016 at 6:53 PM, Chris McGee <newton...@gmail.com> wrote: > >>> For git, there's a wrapper script for github and others. But yes, a fuller > >>> featured git would be good. There are some projects trying to do that in > >>> Go. > >>> Maybe that'll work someday. > >> > >> I know I started a really half-assed, wholly-abandoned implementation > >> here: https://github.com/driusan/go-git > >> when I was starting to learn Go so that I could fix a bug in some of > >> my code on Plan 9 (eventually I just made > >> the change, tested it, and copied the file to a supported git platform > >> over drawterm, and commited it from there..) > >> > >> Who else is trying to do it? > >> > >> - Dave > >> > > > > > > -- > >Ori Bernstein > > > -- Ori Bernstein
Re: [9fans] Plan 9 5th Edition
https://bitbucket.org/oridb/libgit2 If someone wants to actually turn it into a git client, it at least builds (or used to). On Thu, 17 Nov 2016 11:16:20 -0500, Dave MacFarlane <driu...@gmail.com> wrote: > On Wed, Nov 16, 2016 at 6:53 PM, Chris McGee <newton...@gmail.com> wrote: > > For git, there's a wrapper script for github and others. But yes, a fuller > > featured git would be good. There are some projects trying to do that in Go. > > Maybe that'll work someday. > > I know I started a really half-assed, wholly-abandoned implementation > here: https://github.com/driusan/go-git > when I was starting to learn Go so that I could fix a bug in some of > my code on Plan 9 (eventually I just made > the change, tested it, and copied the file to a supported git platform > over drawterm, and commited it from there..) > > Who else is trying to do it? > > - Dave > -- Ori Bernstein
Re: [9fans] off topic - a good Git reference
I have managed to get libgit2 ported to Plan 9, but I haven't had enough time to actually take a shot at making a viable client yet. https://bitbucket.org/oridb/libgit2 It needed a couple of changes to APE to make it work, but they've been integrated into 9front. On Wed, 30 Sep 2015 08:18:33 +0100, Charles Forsyth <charles.fors...@gmail.com> wrote: > On 30 September 2015 at 04:11, erik quanstrom <quans...@quanstro.net> wrote: > > > > > is there someone else interested in write a git tool for plan 9 ? > > > it would be useful, to access git repositories directly. unfortunately, git > is a C program, so it's not very portable. -- Ori Bernstein
Re: [9fans] ... and ##' stuff with pcc?
On Sun, 31 May 2015 11:14:42 +0100 Charles Forsyth charles.fors...@gmail.com wrote: It doesn't understand the named ... variant, which I suppose is more recent tinkering. Use the older __VA_ARGS__. IIRC, the named variant is older, but it's also a GNU extension. -- Ori Bernstein o...@eigenstate.org
Re: [9fans] protection against resource exhaustion
Too complex to use, especially since processes come and go regularly.
IMO, instead of killing processes, it would be better to keep the hanging
behavior in place, but place limits on the resources used by a subsection
of the process tree. Think ulimit, but applying to entire process heirarchies.
On Tue, 27 Jan 2015 16:03:16 +0900
arisawa aris...@ar.aichi-u.ac.jp wrote:
Hello,
i think it will go the same way with fork protection. how do you tell
which program
is at fault? how do you tell a program forking at high frequency, with
short lived
children from a fork bomb? (such as a busy web server.)
only system administrator knows which processes should keep running.
therefore, as Lyndon mentioned, we need a mark “don’t kill by resource
exhaustion” to processes.
if automatic determination is desired, the last stage of /rc/bin/cpurc and
/rc/bin/termrc may be the right place.
i'm not sure i understand what you mean by traditional programming style
here
as plan 9 exists in part to break unix rules.
as Eric mentioned, we have many many codes such as
p = malloc(n);
if(p == nil){
...
}
or
switch(pid = fork()) {/* assign = */
case -1:
sysfatal(fork: %r);
case 0:
...
default:
...
}
I have beeb writing codes believing those error return is working.
--
Ori Bernstein o...@eigenstate.org
[9fans] New Language [Myrddin] On Plan 9/amd64
Myrddin is a language that I put together for fun, but which has developed delusions of usefulness. It's a complete reinvention of the wheel, from the ground up. Some of the major things you'll notice about it: - Type inference. Types are inferred across the whole program. - Algebraic data types. - And their friend, pattern matching. - Generics. - A package system. - Low level control over memory and such. - (Almost) no runtime library. - Self contained. For more details, you can look at the language website: http://eigenstate.org/myrddin Myrddin has been ported to Plan 9/amd64, tested on 9front. I haven't been able to get 9atom's amd64 kernel to boot on virtual hardware yet, so it hasn't been tested there. The compiler and libstd should build out of the box using the provided mkfiles. The libs used for mbld currently need either mbld or gnu make in order to build, or you can run myrbuild by hand. I've provided a script that does the latter. Almost all Plan 9 system calls are directly supported in libsys. As with Linux/Unix, only amd64 targets are supported at the moment. To bootstrap the code on Plan 9, the following script is provided: http://eigenstate.org/myrddin/getmyr.rc You can grab the script and run it as follows: ; hget http://eigenstate.org/myrddin/getmyr.rc getmyr.rc ; chmod +x getmyr.rc ; getmyr.rc ...a lot of cloning and building happens... ; sam helloworld.myr For ease of hacking on Plan 9, I've added mercurial mirrors of the compiler and some libraries to bitbucket: http://bitbucket.com/oridb/mc http://bitbucket.com/oridb/libbio http://bitbucket.com/oridb/libregex http://bitbucket.com/oridb/libcryptohash http://bitbucket.com/oridb/libdate http://bitbucket.com/oridb/mbld There are a number of TODOs, of course: - Libdate needs to learn how to parse Plan 9 timezone files. - Libstd needs to get a smarter allocator for large allocations. - More libraries: lib9p, libdraw, etc... all need to be written. - A bit more thought needs to be given nicer, portable APIs. - More Plan 9 integration. And general work to get Myrddin to the point of day to day usability, int terms of faster binaries, more libraries, and so on. Still, if anyone finds this interesting/useful -- have at it. If you manage to do something neat, let me know! -- Ori Bernstein o...@eigenstate.org
Re: [9fans] New Language [Myrddin] On Plan 9/amd64
Ah, I forgot about that: This is a bug with Ape's printf; It's missing
the %z specifier to print size_ts.
The below patch fixes it, although I seem to remember that 9atom
has a rewritten ape -- I'm not sure if this will apply:
diff -r 40f67c7db147 sys/src/ape/lib/ap/stdio/vfprintf.c
--- a/sys/src/ape/lib/ap/stdio/vfprintf.c Thu Dec 11 17:03:01 2014 +0100
+++ b/sys/src/ape/lib/ap/stdio/vfprintf.c Sun Dec 21 23:32:04 2014 -0800
@@ -75,7 +75,7 @@
0, 0, 0, 0, 0, 0, 0, 0, /* ` a b c
d e f g */
SHORT, 0, 0, 0, LONG, 0, 0, 0, /* h i j k
l m n o */
0, 0, 0, 0, 0, 0, 0, 0, /* p q r s
t u v w */
-0, 0, 0, 0, 0, 0, 0, 0, /* x y z {
| } ~ ^? */
+0, 0, LONG, 0, 0, 0, 0, 0, /* x y z {
| } ~ ^? */
0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0,
On Sun, 4 Jan 2015 11:08:37 -0800
erik quanstrom quans...@quanstro.net wrote:
i am getting a build error:
../myrbuild/6.out -C../6/6.out -M../muse/6.out -l sys sys.myr systypes.myr
ifreq.myr syscall.s util.s
../6/6.out systypes.myr
../6/6.out sys.myr
/tmp/tmp7109d3e2d-sys.myr.s:2 syntax error, last name: zd
nam: LNAME offset.( pointer )
saw ;
/tmp/tmp7109d3e2d-sys.myr.s:2 syntax error, last name: zd
offset: +.con
saw LNAME
/tmp/tmp7109d3e2d-sys.myr.s:4 syntax error, last name: zd
nam: LNAME offset.( pointer )
saw ;
/tmp/tmp7109d3e2d-sys.myr.s:4 syntax error, last name: zd
offset: +.con
saw LNAME
/tmp/tmp7109d3e2d-sys.myr.s:6 syntax error, last name: zd
nam: LNAME offset.( pointer )
saw ;
/tmp/tmp7109d3e2d-sys.myr.s:6 syntax error, last name: zd
offset: +.con
saw LNAME
/tmp/tmp7109d3e2d-sys.myr.s:8 syntax error, last name: zd
nam: LNAME offset.( pointer )
saw ;
/tmp/tmp7109d3e2d-sys.myr.s:8 syntax error, last name: zd
offset: +.con
saw LNAME
/tmp/tmp7109d3e2d-sys.myr.s:10 syntax error, last name: zd
nam: LNAME offset.( pointer )
saw ;
/tmp/tmp7109d3e2d-sys.myr.s:10 syntax error, last name: zd
offset: +.con
saw LNAME
/tmp/tmp7109d3e2d-sys.myr.s:12 syntax error, last name: zd
too many errors
Couldn't run assembler
- erik
--
Ori Bernstein o...@eigenstate.org
Re: [9fans] New Language [Myrddin] On Plan 9/amd64
I could do it pretty easily, although I'd be curious to see what you think makes it harder to write a kernel with bounds checks. At least for me, I'd rather keep them the same. At least on with Intel's current out of order processors, they are shockingly cheap, and can be made much cheaper with (not-yet-implemented) optimizations like value range propagation. If it actually does make a significant performance difference (benchmarks, please), I'd gladly add in a flag. For doing the benchmarks, just delete line 780 of 6/simp.c On Sun, 04 Jan 2015 09:13:20 -0600 Ryan rym...@gmail.com wrote: That looks really neat! One question: are runtime bound checks really necessary? I would at least like a seperate release mode that gets rid of them. Writing a kernel with bound checks would be a mixed nightmare! FYI, please tell me I'm not the only person reminded of Rust... Ori Bernstein o...@eigenstate.org wrote: Myrddin is a language that I put together for fun, but which has developed delusions of usefulness. It's a complete reinvention of the wheel, from the ground up. Some of the major things you'll notice about it: - Type inference. Types are inferred across the whole program. - Algebraic data types. - And their friend, pattern matching. - Generics. - A package system. - Low level control over memory and such. - (Almost) no runtime library. - Self contained. For more details, you can look at the language website: http://eigenstate.org/myrddin Myrddin has been ported to Plan 9/amd64, tested on 9front. I haven't been able to get 9atom's amd64 kernel to boot on virtual hardware yet, so it hasn't been tested there. The compiler and libstd should build out of the box using the provided mkfiles. The libs used for mbld currently need either mbld or gnu make in order to build, or you can run myrbuild by hand. I've provided a script that does the latter. Almost all Plan 9 system calls are directly supported in libsys. As with Linux/Unix, only amd64 targets are supported at the moment. To bootstrap the code on Plan 9, the following script is provided: http://eigenstate.org/myrddin/getmyr.rc You can grab the script and run it as follows: ; hget http://eigenstate.org/myrddin/getmyr.rc getmyr.rc ; chmod +x getmyr.rc ; getmyr.rc ...a lot of cloning and building happens... ; sam helloworld.myr For ease of hacking on Plan 9, I've added mercurial mirrors of the compiler and some libraries to bitbucket: http://bitbucket.com/oridb/mc http://bitbucket.com/oridb/libbio http://bitbucket.com/oridb/libregex http://bitbucket.com/oridb/libcryptohash http://bitbucket.com/oridb/libdate http://bitbucket.com/oridb/mbld There are a number of TODOs, of course: - Libdate needs to learn how to parse Plan 9 timezone files. - Libstd needs to get a smarter allocator for large allocations. - More libraries: lib9p, libdraw, etc... all need to be written. - A bit more thought needs to be given nicer, portable APIs. - More Plan 9 integration. And general work to get Myrddin to the point of day to day usability, int terms of faster binaries, more libraries, and so on. Still, if anyone finds this interesting/useful -- have at it. If you manage to do something neat, let me know! -- Ori Bernstein o...@eigenstate.org -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Check out my website: http://kirbyfan64.github.io/ -- Ori Bernstein o...@eigenstate.org
Re: [9fans] New Language [Myrddin] On Plan 9/amd64
Not yet. I haven't needed a 9p implementation yet; no file servers have bubbled to the top of my queue of code to write at this point, and I'm wary of writing APIs without at least some user in mind. On Sun, 04 Jan 2015 19:51:38 + Skip Tavakkolian skip.tavakkol...@gmail.com wrote: interesting; i especially liked the Why Myrddin section :) i didn't see the obligatory 9P implementation in it; is there one? On Sun Jan 04 2015 at 1:07:47 AM Ori Bernstein o...@eigenstate.org wrote: Myrddin is a language that I put together for fun, but which has developed delusions of usefulness. It's a complete reinvention of the wheel, from the ground up. Some of the major things you'll notice about it: - Type inference. Types are inferred across the whole program. - Algebraic data types. - And their friend, pattern matching. - Generics. - A package system. - Low level control over memory and such. - (Almost) no runtime library. - Self contained. For more details, you can look at the language website: http://eigenstate.org/myrddin Myrddin has been ported to Plan 9/amd64, tested on 9front. I haven't been able to get 9atom's amd64 kernel to boot on virtual hardware yet, so it hasn't been tested there. The compiler and libstd should build out of the box using the provided mkfiles. The libs used for mbld currently need either mbld or gnu make in order to build, or you can run myrbuild by hand. I've provided a script that does the latter. Almost all Plan 9 system calls are directly supported in libsys. As with Linux/Unix, only amd64 targets are supported at the moment. To bootstrap the code on Plan 9, the following script is provided: http://eigenstate.org/myrddin/getmyr.rc You can grab the script and run it as follows: ; hget http://eigenstate.org/myrddin/getmyr.rc getmyr.rc ; chmod +x getmyr.rc ; getmyr.rc ...a lot of cloning and building happens... ; sam helloworld.myr For ease of hacking on Plan 9, I've added mercurial mirrors of the compiler and some libraries to bitbucket: http://bitbucket.com/oridb/mc http://bitbucket.com/oridb/libbio http://bitbucket.com/oridb/libregex http://bitbucket.com/oridb/libcryptohash http://bitbucket.com/oridb/libdate http://bitbucket.com/oridb/mbld There are a number of TODOs, of course: - Libdate needs to learn how to parse Plan 9 timezone files. - Libstd needs to get a smarter allocator for large allocations. - More libraries: lib9p, libdraw, etc... all need to be written. - A bit more thought needs to be given nicer, portable APIs. - More Plan 9 integration. And general work to get Myrddin to the point of day to day usability, int terms of faster binaries, more libraries, and so on. Still, if anyone finds this interesting/useful -- have at it. If you manage to do something neat, let me know! -- Ori Bernstein o...@eigenstate.org -- Ori Bernstein o...@eigenstate.org
Re: [9fans] New Language [Myrddin] On Plan 9/amd64
Thanks to Erik, who helped with squashing a decent number of bugs. On Sun, 4 Jan 2015 00:59:00 -0800 Ori Bernstein o...@eigenstate.org wrote: Myrddin is a language that I put together for fun, but which has developed delusions of usefulness. It's a complete reinvention of the wheel, from the ground up. Some of the major things you'll notice about it: - Type inference. Types are inferred across the whole program. - Algebraic data types. - And their friend, pattern matching. - Generics. - A package system. - Low level control over memory and such. - (Almost) no runtime library. - Self contained. For more details, you can look at the language website: http://eigenstate.org/myrddin Myrddin has been ported to Plan 9/amd64, tested on 9front. I haven't been able to get 9atom's amd64 kernel to boot on virtual hardware yet, so it hasn't been tested there. The compiler and libstd should build out of the box using the provided mkfiles. The libs used for mbld currently need either mbld or gnu make in order to build, or you can run myrbuild by hand. I've provided a script that does the latter. Almost all Plan 9 system calls are directly supported in libsys. As with Linux/Unix, only amd64 targets are supported at the moment. To bootstrap the code on Plan 9, the following script is provided: http://eigenstate.org/myrddin/getmyr.rc You can grab the script and run it as follows: ; hget http://eigenstate.org/myrddin/getmyr.rc getmyr.rc ; chmod +x getmyr.rc ; getmyr.rc ...a lot of cloning and building happens... ; sam helloworld.myr For ease of hacking on Plan 9, I've added mercurial mirrors of the compiler and some libraries to bitbucket: http://bitbucket.com/oridb/mc http://bitbucket.com/oridb/libbio http://bitbucket.com/oridb/libregex http://bitbucket.com/oridb/libcryptohash http://bitbucket.com/oridb/libdate http://bitbucket.com/oridb/mbld There are a number of TODOs, of course: - Libdate needs to learn how to parse Plan 9 timezone files. - Libstd needs to get a smarter allocator for large allocations. - More libraries: lib9p, libdraw, etc... all need to be written. - A bit more thought needs to be given nicer, portable APIs. - More Plan 9 integration. And general work to get Myrddin to the point of day to day usability, int terms of faster binaries, more libraries, and so on. Still, if anyone finds this interesting/useful -- have at it. If you manage to do something neat, let me know! -- Ori Bernstein o...@eigenstate.org -- Ori Bernstein o...@eigenstate.org
Re: [9fans] mk and transitive dependencies (was: gcc not an option for Plan9)
In C, source files do not depend on other source files, they merely depend on headers, eg: foo.$O: foo.c foo.h bar.h bar.$O: bar.c bar.h baz.h baz.$O: baz.c baz.h So, because the dependencies exist and do not depend on the outputs of other commands, it's possible to build the obect files in any order. However, in Go, the exported symbols (the equivalent of headers) are generated from source and put into the libraries, meaning you end up with a dependency graph like this: foo.$O: foo.c bar.o bar.$O: bar.c baz.o baz.$O: baz.c 'mk' can handle that if you explicitly give the list of object files that a source file depends on, but it has no good way of probing it automatically, as a build progresses. making maintaining mkfiles tedious and error prone. Effectively, it means that every time you change an import in Go, you would have to modify the mkfile. 'go build' is able to determine the build order needed automatically without the need to maintain an out-of-line dependency graph that can get out of date. At least in my understanding. On Mon, 25 Mar 2013 10:43:44 +0100 dexen deVries dexen.devr...@gmail.com wrote: On Saturday 23 of March 2013 12:37:17 Rob Pike wrote: (...) and because go install does transitive dependencies correctly, which mk does not. anybody care to explain what is the limitation of mk here? can't wrap my head around it... -- dexen deVries [[[↓][→]]] -- Ori Bernstein o...@eigenstate.org
Re: [9fans] Plan9 development
Compound literal support is unimplemented for arrays. Also, most c99 headers are missing, even the simple ones like stdint.h. It seems most of the work to fix that would be teaching OSTRUCT to work with arrays in com.c *dives back into schoolwork* On Sun, 14 Nov 2010 21:44:07 +, Charles Forsyth fors...@terzarima.net wrote: I have successfully avoided using autoconf and similar stuff in my projects by adhering to strict C99, but in an ironic twist of fate, Plan 9 will be the OS that forces me to use something like autoconf due to the limited C99 support. -- Ori Bernstein
Re: [9fans] proceedings
Correct URL seems to be: http://iwp9.org/iwp95e.pdf On Wed, 13 Oct 2010 13:14:00 -0400, erik quanstrom quans...@quanstro.net wrote: raw proceedings posted www.9fans.net/iwp95e.pdf -- Ori Bernstein
Re: [9fans] LLVM for plan 9?
LLVM is written in C++, so you'd need C++ support on plan 9 first. Probably the easiest way to do that would be to add support for plan 9 binaries to clang, and cross-compile llvm for plan 9 with itself. At least, that's the path I'd take if I was interested in trying. On Tue, 31 Aug 2010 09:10:42 -0700, David Leimbach leim...@gmail.com wrote: I've seen a little bit of information about trying to go to LLVM for Inferno, and getting LLVM on Plan 9 natively (feasibility anyway), and I was wondering if there's any official projects chasing this in earnest? Now that I've got an ARM and an x86 plan 9 instance up, I might have some time, but I can tell you compilers are definitely not my specialty :-). Dave -- Ori Bernstein
Re: [9fans] Radeon driver
On Mon, 1 Jun 2009 21:18:34 -0400 Venkatesh Srinivas m...@acm.jhu.edu wrote: As I understand, the sb600 series has the RS480 IGP, which is a stripped-down r300 (missing some TnL h/w, vertex shaders). The 2D parts of the Linux radeonfb look pretty similar between the r300 and the rs480, so I'd go with yes. No idea about anything newer... I can take a look if people are interested... The new stuff has full specs out (http://x.org/docs/AMD/), but as I understand it, it essentially has no 2d engine at all. To get anything going, you essentially have to initialize and use the 3d engine. -- Ori Bernstein
