So, Russ, just in case nobody else said it to you, thanks so much for
chasing this down. I think the solution you came up with is quite nice
-- need more precision? read more bits! -- and, as a Go user on Plan
9, I'm glad to see Go continuing to work.
Go on Plan 9 is a first-class citizen in u-ro
I can offer up pics of my cat. I have soo many. From a kitten to about 5.
I wouldn't be able to attend but if that's all you need for a table, I'm
sure she would be happy help.
On Sat, Mar 15, 2025, 8:15 AM Daniel Maslowski via 9fans <9fans@9fans.net>
wrote:
> I'll be there for sure as well, we
it's funny how old the problem of process trap handling is in computing.
On Sat, 15 Mar 2025 at 21:33, Charles Forsyth
wrote:
> (I have to admit I'm still wondering what on Earth people are doing with
>> floating point in note handlers.)
>
>
> i only ever used them to resume a process/coroutine
>
> (I have to admit I'm still wondering what on Earth people are doing with
> floating point in note handlers.)
i only ever used them to resume a process/coroutine/whatever. to be fair,
it's trickier since "fp" came to include integer vector instructions and
block moves
On Sat, 15 Mar 2025 at 1
On Thu, Mar 13, 2025 at 08:16:33PM -0400, o...@eigenstate.org wrote:
> Quoth tlaro...@kergis.com:
> > I'm perhaps doing something incorrect.
> >
> > git(1) is available on 9legacy too.
> >
> > But, after launching webcookies and then webfs, when trying to clone a
> > git repository, I have an err
Well, I tried this on my partly-implemented Plan 9 emulator. I sandwiched
Ureg+fpreg between argv and the TOS structure. So note handlers get a fixed
Ureg address that happens to have the fpregs after it. noted(2) is altered to
use the fixed address for Ureg. Plan 9 binaries don't have to change
I think you can preserve the plan 9 model, get an efficient solution, and
do so without adding system calls. We did it on Blue Gene.
On Blue Gene, we had issues with using /dev/bintime because even doing a
read(fd, pointer, size) had a lot of jitter, due to operations such as
okaddr. Overhead was
On 2025/03/08 18:43, Jacob Moody wrote:
Or maybe you start from old
nix and bring in the parts of 9front that you'd need in order to get things
running
on the system you want.
That's a tedious, expensive, but in my opinion wise move. It's also
optional, because clearly 9front is not going to
Following the magic fd's approach, would it make sense to have a
#c/magicfds that can be read to get the list of the FDs or an ID written
into it to get the an existing or new FD returned?
On Mon, Mar 10, 2025, 8:17 AM Russ Cox wrote:
> Hi all,
>
> Cinap said out in the other thread that nsec ha
I'll be there for sure as well, we can sit at the tables upstairs.
If I don't forget it, I'll see that I print a little sign.
You'll see then. :)
On Sat, 15 Mar 2025, 14:06 sirjofri via 9fans, <9fans@9fans.net> wrote:
> Following up on that, it looks like I'll be there. I don't know the
> locati
Following up on that, it looks like I'll be there. I don't know the location
yet, but it seems pretty open so it should be quite possible to find each other
if there are obvious signs.
sirjofri
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups
On Tuesday, March 11, 2025, at 5:09 PM, Russ Cox wrote:
> Personally, I'm not too worried about the cost of fetching the time. A system
> call is fine.
If a read is fast enough, then perhaps open, read, close would also be fast
enough. Or could be made so.
12 matches
Mail list logo