Re: [fonc] Coding Standards
Kjell, Am 25.08.2008 um 01:18 schrieb Kjell Godo: So being without tools is better than being with tools because that increases portability not to be dependent on anything. But I miss the Squeak debugger. What debugger do you use for fonc? [...] I think one cannot overemphasise that this is a project in progress. In other words, it's not completed. In yet other words, there are things one might deem important missing all over the place because the crucial core is being developed first. Have you taken a look at the NSF grant document available from vpri.org, and at the various other sources of documentation on the COLA architecture and philosophy? Frankly, I don't get your point. What was it again? Best, Michael -- Dr.-Ing. Michael Haupt[EMAIL PROTECTED] Software Architecture Group Phone: ++49 (0) 331-5509-542 Hasso Plattner Institute for Fax:++49 (0) 331-5509-229 Software Systems Engineering http://www.swa.hpi.uni-potsdam.de/ Prof.-Dr.-Helmert-Str. 2-3, D-14482 Potsdam, Germany Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Potsdam Amtsgericht Potsdam, HRB 12184 Geschäftsführung: Prof. Dr. Christoph Meinel smime.p7s Description: S/MIME cryptographic signature ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Coding Standards
Michael FIG wrote: Kjell Godo [EMAIL PROTECTED] writes: So what you're saying is that the idc which is written in C compiles C like code into machine code? idc is written in Pepsi. You may be confused because the bootstrap .o.c files are included in the SVN checkout, at least until idc targets Coke instead of C. And then that machine code compiles Smalltalk like idst/Pepsi into machine code? No, GCC compiles the C code (until bootstrap). The idst/Pepsi compiles itself into machine code. And this bootstrapping happens over and over again and not just once or twice in a year. The bootstrapping is when Pepsi and Jolt are unified into Coke, and that need only happen once. Right, but there was also an initial stage in the bootstrapping where a Pepsi compiler was written in C (C++?)... this is Phase 1 in section 6.1 of Accessible Language-Based Environments of Recursive Theories (ALBERT). This one has apparently already been discarded; now we just start from the (Pepsi-compiler-generated) files in boot/. This first one is a normal bootstrap, the exciting one will be when Pepsi and Jolt are unified into Coke. This is Phase 4 in section 6.1 of ALBERT. Cheers, Josh ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Coding Standards
of open instances (like smalltalk). The use of Smalltalk is convenient, but it is not related with Smalltalk syntax, and it is not related with Smalltalk environment (the contents). The use Smalltalk is convenient becasue it is a support to understand how to act using perception (sensing what we have done) and not using definition (saying what is there). Close vs. Open are not contraty but complementary. People working on close systems do not need to face uncertainty and need rules (good abstractions). People working on open systems need instants of excitement continuously to avoid the frustration when facing the limits of object orientation. Hope this lng email can help to do not try to find a language/law/tool for all of us, and let us share good talk understanding that we can complement each other and it is not important to reach a conclusion at low cost or fast, it has been +30years from the first sustainable system in computer media. cheers, Ale. - Original Message - From: Joshua Gargus To: Fundamentals of New Computing Sent: Sunday, August 24, 2008 5:02 PM Subject: Re: [fonc] Coding Standards Michael FIG wrote: Kjell Godo [EMAIL PROTECTED] writes: So what you're saying is that the idc which is written in C compiles C like code into machine code? idc is written in Pepsi. You may be confused because the bootstrap .o.c files are included in the SVN checkout, at least until idc targets Coke instead of C. And then that machine code compiles Smalltalk like idst/Pepsi into machine code? No, GCC compiles the C code (until bootstrap). The idst/Pepsi compiles itself into machine code. And this bootstrapping happens over and over again and not just once or twice in a year. The bootstrapping is when Pepsi and Jolt are unified into Coke, and that need only happen once. Right, but there was also an initial stage in the bootstrapping where a Pepsi compiler was written in C (C++?)... this is Phase 1 in section 6.1 of Accessible Language-Based Environments of Recursive Theories (ALBERT). This one has apparently already been discarded; now we just start from the (Pepsi-compiler-generated) files in boot/. This first one is a normal bootstrap, the exciting one will be when Pepsi and Jolt are unified into Coke. This is Phase 4 in section 6.1 of ALBERT. Cheers, Josh -- ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Coding Standards
Hello Joshua, Saturday, August 23, 2008, 9:42:38 AM, you wrote: I think that (part of) the point is to be able to bootstrap with minimal tool support, and thereafter to be self-supporting. The bootstrap process is described better than I can in Section 6.1 of Accessible Language-Based Environments of Recursive Theories, available on the VPRI website. C is described as a portable high-level assembly language. Ian already wrote wrote most of the code in idst/Pepsi which is Smalltalk-like. Most of .c files (all? I can't find anything else, except GC which is from http://www.hpl.hp.com/personal/Hans_Boehm/gc ) for Pepsi are generated by idc (Pepsi compiler), and they're in that form just for bootstrapping. -- Best regards, Derekmailto:[EMAIL PROTECTED] CCNA, SCSA, SCNA, LPIC, MCP certified Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Coding Standards
So what you're saying is that the idc which is written in C compiles C like code into machine code? And then that machine code compiles Smalltalk like idst/Pepsi into machine code? The idst/Pepsi compiles itself into machine code. And this bootstrapping happens over and over again and not just once or twice in a year. I would like a fonc debugger. One for the C, one for the Smalltalk, one for the Lisp. Better yet all together. picoLARC has syntax trees that have the original source code embedded into them and then those syntax trees are embedded into the executable objects so that when the executables evaluate they select the source code that gave rise to them in the debugger which is just a text pane. Macro calls look like message sends that don't put a new activation on the stack. It's like Smalltalk but Smalltalk recompiles each method in the debugger to get a byte code to source code map. Could text selection beginning and end numbers be embedded into the generated machine code so that prior to each thing executing source code could be selected in some window? ( select pane begin end ) ( stopAndDisplay localData ) ( execute something ) ( stop ) The machine code would explode in size but so what. You turn it off when you want. On Sat, Aug 23, 2008 at 9:58 AM, Derek Kuliński [EMAIL PROTECTED] wrote: Hello Joshua, Saturday, August 23, 2008, 9:42:38 AM, you wrote: I think that (part of) the point is to be able to bootstrap with minimal tool support, and thereafter to be self-supporting. The bootstrap process is described better than I can in Section 6.1 of Accessible Language-Based Environments of Recursive Theories, available on the VPRI website. C is described as a portable high-level assembly language. Ian already wrote wrote most of the code in idst/Pepsi which is Smalltalk-like. Most of .c files (all? I can't find anything else, except GC which is from http://www.hpl.hp.com/personal/Hans_Boehm/gc ) for Pepsi are generated by idc (Pepsi compiler), and they're in that form just for bootstrapping. -- Best regards, Derekmailto:[EMAIL PROTECTED] CCNA, SCSA, SCNA, LPIC, MCP certified Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Coding Standards
Ah, space wars and brace wars rise again!
I'd like to propose that no standard be imposed...until a beautifier (text
filter) has been created to implement such a norm. After which, everyone
can peer at the code through their own rose-colored beautifiers.
;-)
Cheers,
--ken ritchie (atlanta)
PS, I'll set mine to 4 columns. That's a factor of 8, and close to an
optimum setting for human reading performance...according to a study (many
moons ago) aired by Ben Shneiderman and the HCIL folks at UMD (They reported
peak performance around 3 to 4 columns, back in the days of line printers.
Anyone remember greenbar tractor paper?)
On Sun, Jun 22, 2008 at 6:45 AM, Bert Freudenberg [EMAIL PROTECTED]
wrote:
Am 22.06.2008 um 11:41 schrieb John Leuner:
What do you use a teletype for?
John
http://en.wikipedia.org/wiki/Teletype
SCNR,
- Bert -
On Sat, 2008-06-21 at 11:45 -0700, Ian Piumarta wrote:
Set your tabs stops every eight columns and the source will be
aligned properly.
I like the tabs in the source because I can move around indented
lines faster (and the file is a few bytes shorter). I also like
braces lined up like this
if (foo)
{
bar();
}
which would mean a tab width of 2 to make everything be tabbist -
which might just as well stay as spaces. (But tabs every 2 would
also make the source almost immediately run off the right hand edge
when viewed on my teletype, with its tabs hard-wired at every eighth
column, not to mention the cacophony of bell ringing that would ensue
every time it reached the margin set 10 spaces before the right-hand
edge of the paper.)
FWIW, I don't do anything special to Emacs (which I use when away
from my teletype) to get this behaviour - tabs every eight, and
compressing multiple spaces into single tab characters when possible,
is the default behaviour. Works for me, but then I still think of my
computer as a typewriter - with pretty colours and unlimited built-in
tippex.
Spaced-out people should refer to expand(1).
HTH,
Ian
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Coding Standards
On Jun 22, 2008, at 2:41 AM, John Leuner wrote: What do you use a teletype for? Backing up my sources to punched tape. Cheers, Ian PS: if you're taking me seriously in this tread, it's time to stop. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Coding Standards
Set your tabs stops every eight columns and the source will be
aligned properly.
I like the tabs in the source because I can move around indented
lines faster (and the file is a few bytes shorter). I also like
braces lined up like this
if (foo)
{
bar();
}
which would mean a tab width of 2 to make everything be tabbist -
which might just as well stay as spaces. (But tabs every 2 would
also make the source almost immediately run off the right hand edge
when viewed on my teletype, with its tabs hard-wired at every eighth
column, not to mention the cacophony of bell ringing that would ensue
every time it reached the margin set 10 spaces before the right-hand
edge of the paper.)
FWIW, I don't do anything special to Emacs (which I use when away
from my teletype) to get this behaviour - tabs every eight, and
compressing multiple spaces into single tab characters when possible,
is the default behaviour. Works for me, but then I still think of my
computer as a typewriter - with pretty colours and unlimited built-in
tippex.
Spaced-out people should refer to expand(1).
HTH,
Ian
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
[fonc] Coding Standards
Now that Michael has set up repositories to which patches can be submitted, it would be good for the project to have a few coding standards enforced for the contributions. I would like to see an all spaces, no tabs standard. The handful of files in the current codebase which I looked at all had both tabs and spaces. Oh, and is there a preferred way to submit patches (mailing list, direct email, wiki)? -Karl ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
