Hannes Hirzel hannes.hirzel.squeaklist@bluewin.ch wrote:
Marco Paga mail@marco-paga.de wrote:
I like the "prevalence" ideas a lot. My quick summary:
- The business objects are kept in RAM, yet protected from system
crashes by the logging and recovery mechanisms.
It might be a good idea to do the log in XML format. See SIXX on SqueakMap.
Or as a sequence of Squeak do-its.
Hannes
Hannes Hirzel hannes.hirzel.squeaklist@bluewin.ch wrote:
Hannes Hirzel hannes.hirzel.squeaklist@bluewin.ch wrote:
Marco Paga mail@marco-paga.de wrote:
I like the "prevalence" ideas a lot. My quick summary:
- The business objects are kept in RAM, yet protected from system
crashes by the logging and recovery mechanisms.
It might be a good idea to do the log in XML format. See SIXX on SqueakMap.
Or as a sequence of Squeak do-its.
Yes, much better. :-) We have one good language (Smalltalk) why not use it? All this focus on XML (in the IT industry over all that is) is really tiresome.
Btw, SqueakMap uses a very similar approach as Prevayler - in fact more or less the exact same approach. ;-)
regards, Göran
Hi,
Yes, much better. :-) We have one good language (Smalltalk) why not use it? All this focus on XML (in the IT industry over all that is) is really tiresome.
Tiresome, indeed. But I think SIXX has some advantages for serious, robust systems.
- It automatically resolves circular or shared references. (In "do it" approach, you have to write it on your own).
- It is safe. ("Do it" could be a security hall. You can insert dangerous expressions).
- It is portable. (SIXX has been ported to 3 Smalltalks. It can be converted to other data structures by processing parsed dom tree).
So I think it is oversimplified to say "much better".
--- [:masashi | ^umezawa]
"Masashi Umezawa" umejava@mars.dti.ne.jp wrote:
Hi,
Yes, much better. :-) We have one good language (Smalltalk) why not use it? All this focus on XML (in the IT industry over all that is) is really tiresome.
Tiresome, indeed. But I think SIXX has some advantages for serious, robust systems.
- It automatically resolves circular or shared references.
(In "do it" approach, you have to write it on your own).
Yes, true. On the other hand Smalltalk can use the "language" of the model at hand. Smalltalk is simply a more powerful language than XML. But sure, if we are talking about simply representing state in an external form (serializing that is) then I agree - no point in implementing a general serialzer - there are plenty around including SIXX.
- It is safe.
("Do it" could be a security hall. You can insert dangerous expressions).
True.
- It is portable.
(SIXX has been ported to 3 Smalltalks. It can be converted to other data structures by processing parsed dom tree).
Yes, SIXX definitely is cool.
So I think it is oversimplified to say "much better".
Yes, I agree. I wasn't putting down SIXX - I was more cheerfully noticing that someone remembered the good old chunk format! We sometimes forget that Smalltalk (the language) can be used for these things. And you avoid the burden of "yet another language to master".
For example, SqueakMap needs no XML package to do it's logging and since I use the protocol in the class SqueakMap it is very compact and domain specific. And I don't really "serialize" anything.
regards, Göran
Hello All,
Just out of curiosity does anyone know where development of the Jitter is at? I heard that Ian was working on J5 and I did a quick search of the archive and couldn't find anything interesting. I am really just curious about it.
Thanks, Eric
__________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com
Hi All,
Is J5 been written in SLang?
Ale.
----- Original Message ----- From: "Eric Merritt" cyberlync@yahoo.com To: squeak-dev@lists.squeakfoundation.org Sent: Monday, February 17, 2003 1:38 PM Subject: Jitter
Hello All,
Just out of curiosity does anyone know where development of the Jitter is at? I heard that Ian was working on J5 and I did a quick search of the archive and couldn't find anything interesting. I am really just curious about it.
Thanks, Eric
Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com
On Monday, February 17, 2003, at 05:11 PM, Ian Piumarta wrote:
Is J5 been written in SLang?
Given the absence of Slang++ it's written in the next best thing: 20,000 lines of delicious C++.
Speaking of which, I was nosing around the Xanadu/Udanax site not to long ago and ran across a description of their Xtalk / X++ system. Apparently it's a subset-of-Smalltalk to subset-of-C++ compiler, just the ticket for Slang++.
Lots of support code has been released, but not the actual translator. Anyone know what the status of their "disentanglement" process is? Anybody think this would be useful to Squeak?
Cheers,
Colin
On Mon, 17 Feb 2003, Eric Merritt wrote:
Hello All,
Hi Eric,
Just out of curiosity does anyone know where development of the Jitter is at?
It's stalled. I wanted make a version that worked on Mac for Dan to play with and the easiest route appeared to be to make it work on OS X which he was planning to install. Making j5 work on OS X meant making the Unix VM work on OS X, but that particular "subproject" got slightly out of hand and finally turned into a significant part of the hacking I've done during the last 5 or 6 months.
The current non-optimising compiler generates native code with all the hooks, profiling, recompilation triggers and support in place to do adaptive compilation based on runtime type feedback. (I was about to embark on the first round of adaptive compilation when I became distracted by OS X.) The emphasis is on reducing compilation time to an absolute minimum: what's important is generating code for lots of methods quickly (compilation shouldn't introduce any detectable pauses in execution) but which includes profiling (to record type, sender and frequency information to drive an optimising compiler). The real benefits come from recompilation using this optimising compiler, once runtime type behaviour is known, whose emphasis is on producing the fastest possible code at the expense of compilation time. Since this compiler is invoked far less frequently than the non-optimising one, its longer compilation times shouldn't introduce detectable pauses either.
The non-optimising compiler already produces stable code (where "stable" means I don't know how to crash the code by writing bizarre methods, abusing contexts or exceptions, etc., within the image) for PPC and 386. The first part of the optimising compiler was the next thing on the to-do list when OS X came along and preempted it.
I heard that Ian was working on J5 and I did a quick search of the archive and couldn't find anything interesting.
I don't think there's been any discussion of it here.
I am really just curious about it.
To satisfy your curiosity I checked it out for you here:
http://www-sor.inria.fr/~piumarta/squeak/unix/j5
Although I don't suggest you try this at home, the above could be dropped into a 3.2 tree (next to the "platforms" and "src" dirs) and will build a working j5 (provided the regular VM has already been built in a dir called "bld" at the same level). It generates code for PPC on Unix and 386 on Unix or Windows. (It probably works with the 3.5 tree too, modulo the Quartz code not bothering to look for "j_interpret" before launching the interpreter, so my objective of making it work on Mac OS might already have been met. Some trivial additions are required to the win32 tree to make it work, but they're outside the tree that I checked out. If you're curiosity is instatiable then I could check out my modified win32 tree too.)
The above directory contains the answers to any and all questions you might have regarding j5, albeit in an _extremely_ undigested form. ;)
I'm hearing encouraging things about Anthony's latest run at his closure work. When I get round to picking up j5 from where I left off I'll probably start by looking at what he's been up to and adapt j5 to work with it instead of with an unmodified "traditional" image.
Regards, Ian
The above directory contains the answers to any and all questions you might have regarding j5, albeit in an _extremely_ undigested form. ;)
I'm hearing encouraging things about Anthony's latest run at his closure work. When I get round to picking up j5 from where I left off I'll probably start by looking at what he's been up to and adapt j5 to work with it instead of with an unmodified "traditional" image.
Regards, Ian
Oh gawd, YES! Finally. I've been wanting to look around such a system for some time.
6 months to port to MacOSx? Yeouch. So much for leveraging Unix... >.<
-Daniel
Daniel,
On Mon, 17 Feb 2003, Daniel Joyce wrote:
6 months to port to MacOSx? Yeouch. So much for leveraging Unix... >.<
To be fair to OS X I think I should point out that absolutely everything in the Unix VM other than the window and sound code compiled out of the box with no modifications whatsoever.
The 5 months is due entirely to my limitations and comes from having to learn from scratch how to write a MacOS X GUI application, then how to write the same application while avoiding anything to do with InterfaceBuilder, after which the window/keyboard/mouse/drag code was more or less working in under a week. Much of the unreasonable amount of extra time came from my deciding that I wanted sound i/o to work too (another learning curve) followed by OpenGL (which accounts for more than a month of various hassles all by itself). Then a week or so was put into refactoring everything so that X11 and Quartz could live happily side by side in both the source and binaries. Maybe another week or so was lost to figuring out and fixing a bug in autoconf and rewriting the FFI support to be independent of libffi. Most of the time therefore represents my scrambling up several learning curves of varying steepness, with development accounting for far less than 50% of the total.
Regards,
Ian
On Tuesday, February 18, 2003, at 03:37 Uhr, Ian Piumarta wrote:
Daniel,
On Mon, 17 Feb 2003, Daniel Joyce wrote:
6 months to port to MacOSx? Yeouch. So much for leveraging Unix... >.<
To be fair to OS X I think I should point out that absolutely everything in the Unix VM other than the window and sound code compiled out of the box with no modifications whatsoever.
Yup, and a long time ago, too...
The 5 months is due entirely to my limitations and comes from having to learn from scratch how to write a MacOS X GUI application, ...
Of course, you could have just used one that already exists, and took a fraction of the time to write because, oh well, it uses InterfaceBuilder and AppKit etc.
Marcel
Ian,
Thanks for the response. I am glad its still (somewhat) under development.
To satisfy your curiosity I checked it out for you here:
Cool, thanks
Some trivial additions are required
to the win32 tree to make it work, but they're outside the tree that I checked out. If you're curiosity is instatiable then I could check out my modified win32 tree too.)
I wouldn't say I that curios. I don't use win32 very often.
Thanks again, Eric
__________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com
Hi Ian,
have been met. Some trivial additions are required to the win32 tree to make it work, but they're outside the tree that I checked out. If you're curiosity is instatiable then I could check out my modified win32 tree
My curiostity is instatiable ;-)
Please let me know where I can find it. (Does it build out of the box )
Cheers,
PhiHo.
----- Original Message ----- From: "Ian Piumarta" ian.piumarta@inria.fr To: squeak-dev@lists.squeakfoundation.org Sent: Monday, February 17, 2003 8:08 PM Subject: Re: Jitter
On Mon, 17 Feb 2003, Eric Merritt wrote:
Hello All,
Hi Eric,
Just out of curiosity does anyone know where development of the Jitter is at?
It's stalled. I wanted make a version that worked on Mac for Dan to play with and the easiest route appeared to be to make it work on OS X which he was planning to install. Making j5 work on OS X meant making the Unix VM work on OS X, but that particular "subproject" got slightly out of hand and finally turned into a significant part of the hacking I've done during the last 5 or 6 months.
The current non-optimising compiler generates native code with all the hooks, profiling, recompilation triggers and support in place to do adaptive compilation based on runtime type feedback. (I was about to embark on the first round of adaptive compilation when I became distracted by OS X.) The emphasis is on reducing compilation time to an absolute minimum: what's important is generating code for lots of methods quickly (compilation shouldn't introduce any detectable pauses in execution) but which includes profiling (to record type, sender and frequency information to drive an optimising compiler). The real benefits come from recompilation using this optimising compiler, once runtime type behaviour is known, whose emphasis is on producing the fastest possible code at the expense of compilation time. Since this compiler is invoked far less frequently than the non-optimising one, its longer compilation times shouldn't introduce detectable pauses either.
The non-optimising compiler already produces stable code (where "stable" means I don't know how to crash the code by writing bizarre methods, abusing contexts or exceptions, etc., within the image) for PPC and 386. The first part of the optimising compiler was the next thing on the to-do list when OS X came along and preempted it.
I heard that Ian was working on J5 and I did a quick search of the archive and couldn't find anything interesting.
I don't think there's been any discussion of it here.
I am really just curious about it.
To satisfy your curiosity I checked it out for you here:
http://www-sor.inria.fr/~piumarta/squeak/unix/j5
Although I don't suggest you try this at home, the above could be dropped into a 3.2 tree (next to the "platforms" and "src" dirs) and will build a working j5 (provided the regular VM has already been built in a dir called "bld" at the same level). It generates code for PPC on Unix and 386 on Unix or Windows. (It probably works with the 3.5 tree too, modulo the Quartz code not bothering to look for "j_interpret" before launching the interpreter, so my objective of making it work on Mac OS might already have been met. Some trivial additions are required to the win32 tree to make it work, but they're outside the tree that I checked out. If you're curiosity is instatiable then I could check out my modified win32 tree too.)
The above directory contains the answers to any and all questions you might have regarding j5, albeit in an _extremely_ undigested form. ;)
I'm hearing encouraging things about Anthony's latest run at his closure work. When I get round to picking up j5 from where I left off I'll probably start by looking at what he's been up to and adapt j5 to work with it instead of with an unmodified "traditional" image.
Regards, Ian
On Tue, 18 Feb 2003, PhiHo Hoang wrote:
have been met. Some trivial additions are required to the win32 tree to make it work, but they're outside the tree that I checked out. If you're curiosity is instatiable then I could check out my modified win32 tree
My curiostity is instatiable ;-) Please let me know where I can find it.
It's now at the same URL I posted earlier.
(Does it build out of the box )
Probably.
Ian
Hi,
Yes, I agree. I wasn't putting down SIXX - I was more cheerfully noticing that someone remembered the good old chunk format! We sometimes forget that Smalltalk (the language) can be used for these things. And you avoid the burden of "yet another language to master".
Yes. I agree with that. Sometimes we tend to use some buzzword languages only because they are thought to be cool.
For example, SqueakMap needs no XML package to do it's logging and since I use the protocol in the class SqueaMap it is very compact and domain specific. And I don't really "serialize" anything.
Domain specific way is the most powerful (and simple) way to achieve functionalities. On the contrary, generic way is somewhat complicated but provides flexibility if applied appropriately.
So, we always have to consider and select the right direction. ;->
--- [:masashi | ^umezawa]
squeak-dev@lists.squeakfoundation.org
-
Alejandro F. Reimondo -
Colin Putney -
Daniel Joyce -
Eric Merritt -
goran.hultgrenï¼ bluefish.se -
Hannes Hirzel -
Ian Piumarta -
Marcel Weiher -
Masashi Umezawa -
PhiHo Hoang -
Simon Michael