mulix
Sun, 05 Aug 2001 02:31:12 -0700
On Sun, 5 Aug 2001, Shlomi Fish wrote: > On Fri, 3 Aug 2001, mulix wrote: > > > On Sun, 29 Jul 2001, Shlomi Fish wrote: > > > > > The internals and behaviours of the MAYBE and the G-Machine are described > > > in the book, which is still in print and available in "Sifriyath Hadikan". > > > > > > My question is: do you think it will be a valuable project to write these > > > simulators so they would be able to run on Linux, but would also have a > > > back-end that is portable enough to run on any other 32-bit and 64-bit > > > system? This project has the advantage that those who take it will become > > > familiar with the internals of a full-fledged computer, which would be a > > > good experience in digital electronics. > > > > i'm not sure how worthy a project it would be, if you consider the > > following points: > > > > * how much hack value does this project have? or to put it another way, > > how much fun will we have doing it? > > > > If you ask me, touching/deleting/polling a file does not exactly have too > much hack value either. (not to start a flame war here, but it is a pretty > trivial thing to do). This project would give us useful experience in > digital electronics and I have some very good idea for a wise design of > it. I can elaborate on my ideas if you care. not to start a flame war either, but that is entirely *not* what the project is about. the project is about working together, reviewing each other's code, solving problems (emil's refreshd, encoding both biditext base state and r2l state in one file) and in general writing quality software (compare the "new style" biditext and "old style" biditext. they do the same thing, but the glue code is nothing alike...) > > * will it be usefull to anyone, excepts students taking this class? > > since i haven't read the book (though i probably will, based on your > > recommendation), i have no idea what is the scope of the work required, > > which is another issue to consider. > > It's bigger than R2L, but if we split it among us, it should not too much > time. We can have one session in which we decide on which language to us, > which APIs, what the design would be, etc. And then several sessions for > coordinating the development. And remember that it involves two separate > programs, which we can do at different stages with a break for something > else in the middle. i'd hesitate to take on a project whose time to completion cannot be estimated. i think that until we get some more developers (hint, hint, lin-club people) we should stick to small scale projects. -- mulix http://www.advogato.com/person/mulix linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead