I suggest a new fork or possibly a new orientation for the next Squeak release: Adopt Cuis as the core image and focus on killer applications to attract new Smalltalk users. Thousands of downloads are recorded on CNet for simple apps like a voice recorder.
They could all be using and learning Smalltalk. Same for many other applications. That would help make Smalltalk popular again. Recently I found Squeak / Cuis contains many Sound classes. So I wrote up an email suggesting it to a community college teacher friend who had asked for a sound recorder. Imagine my embarrassment when I found the files Squeak supports doesn't include .mp3.
Squeak has so much unfinished half starts at programs, why not adopt Juan's work to flush the unnecessary, then get started on building a serious applications team to build truly useful free code.
Another example, Roxio is a million dollar software company making a video recorder app. which is not as good as an ordinary VCR and not supported (they have a staff but try getting any real help). Squeak could be capturing a slice of that market and enticing users to learn Smalltalk! And source code can substitute for most support.
Another example, Solid Works is a 3D object drafting program that is simple and gets many thousands of users away from AutoDesk. Can Smalltalk deliver most or all of that function with a FFI to openGL and some programming? Certianly!
Finally, the one complaint I've heard on the job about Smalltalk is it's slow. I recently added several thousand classes and find simply clicking on the class in a browser is now slow to respond. When end-users, not programmers, can type at 80 words a minute and more in a C app. or they can be limited to 30 wpm or less in a Smalltalk app. they demand C. The new VM was a good improvement, now try to solve the speed issues in the image.
Thanks, Kirk Fraser
|
Cuis is a good partial solution. So is Craig Latta's Spoon.
Better will be developing a GOOD IPC strategy so that we can spawn dedicated images from Cuis that contain only the code necessary to run a task in its own process, using Spoon to cull the unneeded classes. L. On 9/7/11 9:52 AM, Overcomer Man wrote:
|
In reply to this post by Kirk Fraser
Inline below.
On Wed, Sep 7, 2011 at 9:52 AM, Overcomer Man <[hidden email]> wrote: --
-1
+1. If I was allowed to do +100, you'd have that in a heartbeat:)
:D I like the way you think!
Juan, I think it's time to bring out your synth, my friend! So .mp3 isn't necessarily a deal breaker. MPEG should be convertible to WAV, but FWIW, you're right. Squeak needs a Winamp/XMMS killer. Between this, and a standards-complient web browser (read: nightmarish rabbit-hole) I can practically ditch my operating system and live in Squeakland all the time. Wouldn't that be *radical?*
Worth pointing out: applications which use Morphic will take real work to make run over Cuis. Morphic in Cuis is a whole new breed of animal; fast, lean, beautiful, and completely different from the tangle which many applications expect to find down there.
Yes! Redhat sells an open source operating system. We have an operating system that's actually pretty! Why not Mousehat or something (obviously I'm not from marketing)? I dig the entrepreneurial angle, Overcomer Man. I've been thinking about this stuff for years. I dream of a BSD kernel and nothing else but drivers and Squeak. Web browser is still an issue, but it's no problem money can't solve.
Have you played with OpenQwaq? It has tools that do some of this stuff in a very natural way. If we can make these parts loadable packages, the whole GPL thing becomes a non-issue for end users. Can't go into the core system, but as a loadable package, everybody wins. I want to see what we can do with a Cintiq graphics tablet, build ourselves a Robot Draftsman. Long live Sketchpad!
Eh... Smalltalk invented fast. Smalltalk's little sister, Self, invented *very fast*. JIT and polymorphic inline caches make this a virtual non-issue. And you can optimize for whatever you want because you control the vertical, you control the horizontal. See also, L Peter Deutsch, David Ungar, Eliot Miranda.
We have a fast VM now. This is a non-issue.
Hmm. Have you tried using the performance spy to figure out where the bottleneck is? Generally, most programs spend 80% of their time in 20% of their code. A Pareto relationship. There is likely something running which is sending more messages than it needs to be.
How big is that image file, out of curiosity?
Sure, I mean. Cuis?
Kirk, I really enjoyed your spirited comments. While I *do* think you have some great ideas for new apps, I personally think the best plan is to throw in on making the apps that Smalltalk programmers presently care a great deal for (e.g., Seaside) run atop Cuis. This will take a concerted effort.
Cuis is a lovely little system. I find it the most broadly usable Smalltalk -- certainly better looking than any other (antialiasing goes a long way with rounded window corners, thanks again Juan) -- and I would love so see someone experiment with the combination of Spoon and Cuis (to address Lawson's point.)
Craig, if I wanted to try to Spoon-out Cuis, where would I start?
Casey Ransberger |
In reply to this post by Kirk Fraser
On Wed, 7 Sep 2011, Overcomer Man wrote:
> I suggest a new fork or possibly a new orientation for the next Squeak > release: I guess we have too many forks already (compared to the number of active developers). > Adopt Cuis as the core image and focus on killer applications to attract new > Smalltalk users. Cuis is nice, but lacks features that are important for those killer apps (e.g. internationalization). Also throwing aways years of work (3.8, 3.9, 4.1, 4.2 and 4.3) sounds like a bad idea. We should pick good stuff from Cuis (and Pharo) instead. To make the image smaller we should do two things (in parallel): - craving (make packages unloadable, remove dependencies, split packages) - building (use Spoon to rebuild the current image) To make this happen we have to start with writing tests, which "document" the expected behavior of the system. So when we change it, we can be sure that we didn't lose anything important. > Thousands of downloads are recorded on CNet for simple apps like a voice > recorder. > They could all be using and learning Smalltalk. Same for many other > applications. > That would help make Smalltalk popular again. If popularity is the goal, then this is a possible path, though most users won't care about the language their software is written in. > > Recently I found Squeak / Cuis contains many Sound classes. So I wrote up > an email suggesting it to a community college teacher friend who had asked > for a sound recorder. Imagine my embarrassment when I found the files > Squeak supports doesn't include .mp3. I guess it does (there's Mpeg3Plugin). Btw I think using PortAudio or LibVLC may have advantages over the current platform specific implementations of audio and video support. > > Squeak has so much unfinished half starts at programs, why not adopt Juan's > work to flush the unnecessary, then get started on building a serious > applications team to build truly useful free code. See above. > > Another example, Roxio is a million dollar software company making a video > recorder app. which is not as good as an ordinary VCR and not supported > (they have a staff but try getting any real help). Squeak could be > capturing a slice of that market and enticing users to learn Smalltalk! And > source code can substitute for most support. > > Another example, Solid Works is a 3D object drafting program that is simple > and gets many thousands of users away from AutoDesk. Can Smalltalk deliver > most or all of that function with a FFI to openGL and some programming? > Certianly! > > Finally, the one complaint I've heard on the job about Smalltalk is it's > slow. I recently added several thousand classes and find simply clicking on > the class in a browser is now slow to respond. When end-users, not Interesting. Did you add all classes to the same class category? In that case it will be slow, but this is a unrealistic case. I'm not saying we shouldn't fix it, but it's something that has a pretty low priority. > programmers, can type at 80 words a minute and more in a C app. or they can > be limited to 30 wpm or less in a Smalltalk app. they demand C. The new VM > was a good improvement, now try to solve the speed issues in the image. Are there other speed issues? Levente > > Thanks, > Kirk Fraser > |
In reply to this post by Casey Ransberger-2
On Wed, Sep 7, 2011 at 9:27 AM, Casey Ransberger
<[hidden email]> wrote: > Inline below. > > On Wed, Sep 7, 2011 at 9:52 AM, Overcomer Man <[hidden email]> > wrote: >> >> I suggest a new fork [snip] > :D I like the way you think! > >> >> Recently I found Squeak / Cuis contains many Sound classes. So I wrote up >> an email suggesting it to a community college teacher friend who had asked >> for a sound recorder. Imagine my embarrassment when I found the files >> Squeak supports doesn't include .mp3. > > Juan, I think it's time to bring out your synth, my friend! So .mp3 isn't > necessarily a deal breaker. MPEG should be convertible to WAV, but FWIW, > you're right. Squeak needs a Winamp/XMMS killer. Between this, and a > standards-complient web browser (read: nightmarish rabbit-hole) I can > practically ditch my operating system and live in Squeakland all the time. > Wouldn't that be *radical?* That is exactly what I want for OSP, the Squeak desktop *IS* the desktop. >> Squeak has so much unfinished half starts at programs, why not adopt >> Juan's work to flush the unnecessary, then get started on building a serious >> applications team to build truly useful free code. > > Worth pointing out: applications which use Morphic will take real work to > make run over Cuis. Morphic in Cuis is a whole new breed of animal; fast, > lean, beautiful, and completely different from the tangle which many > applications expect to find down there. Not sure how to interpret this. Morphic is key to OSP, as it is to OLPC. Are you saying that Morphic will not run on Cuis without modification, but should it be ported the underlying system is fast and lean? >> Another example, Roxio is a million dollar software company making a video >> recorder app. which is not as good as an ordinary VCR and not supported >> (they have a staff but try getting any real help). Squeak could be >> capturing a slice of that market and enticing users to learn Smalltalk! And >> source code can substitute for most support. > > Yes! Redhat sells an open source operating system. We have an operating > system that's actually pretty! Why not Mousehat or something (obviously I'm > not from marketing)? I dig the entrepreneurial angle, Overcomer Man. I've > been thinking about this stuff for years. I dream of a BSD kernel and > nothing else but drivers and Squeak. Web browser is still an issue, but it's > no problem money can't solve. Maybe implementing a window frame class that allows apps to run in a squeak window is all we need. Rather than build a web browser in Squeak, open Mozilla it in a Squeak window. Think X tunneling on the same host. -- Gary Dunn Open Slate Project http://openslate.org/ Honolulu |
In reply to this post by Levente Uzonyi-2
On 9/7/11 6:24 PM, "Levente Uzonyi" <[hidden email]> wrote: > building (use Spoon to rebuild the current image) I think Spoon is the future, but we should take PharoKernel as next step. Edgar |
In reply to this post by Levente Uzonyi-2
Inline.
On Wed, Sep 7, 2011 at 2:24 PM, Levente Uzonyi <[hidden email]> wrote:
+1
Yes, we should merge the best things from Squeak into Cuis, We should merge the best things from Cuis into Squeak. Until all are one.
WRT internationalization, though, I do feel that most end users don't need 20 languages they don't speak in the core system. Most users will want to use the system in a primary language. This stuff should all be available as rock-solid external packages. Not saying it isn't important, not saying that at all. If we hope to rebase Etoys on Squeak, internationalization is essential.
To make this happen we have to start with writing tests, which "document" +1! A living system needs a living specification, and the closest thing I know how to do to a living specification is a great suite of tests.
Let's start by merging the tests.
Popularity, along with usability, *is* _massively_ important. Picture three clocks in your mind. For every second, Ruby gains a second. For every second, Squeak and Pharo lose two.
If we lose badly, we've wasted our time.
Good news.
See below.
I have a feeling there's an obvious fix for this. He might have ended up with a dictionary larger than was optimized for. Not going to worry about it until we see a performance profile.
'Cause Levente will probably be all over that:) straight up wrecking the bad numbers with new optimized code. 'Cause he's pretty much awesome that way.
Levente Casey Ransberger |
In reply to this post by Levente Uzonyi-2
Levente Uzonyi wrote:
> On Wed, 7 Sep 2011, Overcomer Man wrote: > > ... > Cuis is nice, but lacks features that are important for those killer > apps (e.g. internationalization). That is not needed in a kernel image. It should be in an optional package. > Also throwing aways years of work (3.8, 3.9, 4.1, 4.2 and 4.3) sounds > like a bad idea. Cuis is not Squeak 3.7. Nearly all the changes done in these years in Squeak, that belong in a kernel image, have been integrated in Cuis. For instance, I am the only guy who studied the migration of the image to Closures format in enough detail to be able to update an image without any help from Eliot. That's how seriously I take being updated to latest Squeak. I have already integrated Squeak changes up to end of August (i.e. a week ago). These will be in the next release of Cuis, and are available for anyone who asks. Besides, as you know, quite a bit of the changes done in Squeak in the last couple of years actually came from Cuis. > We should pick good stuff from Cuis (and Pharo) instead. > To make the image smaller we should do two things (in parallel): > - craving (make packages unloadable, remove dependencies, split packages) > - building (use Spoon to rebuild the current image) Growing back the image with Spoon is much easier if you already start with a clean image, like Cuis. Same for loading packages back: half of the work is already done. > ... Cheers, Juan Vuletich |
In reply to this post by Gary Dunn-2
Gary Dunn wrote:
> On Wed, Sep 7, 2011 at 9:27 AM, Casey Ransberger > <[hidden email]> wrote: > > ... >> Worth pointing out: applications which use Morphic will take real work to >> make run over Cuis. Morphic in Cuis is a whole new breed of animal; fast, >> lean, beautiful, and completely different from the tangle which many >> applications expect to find down there. >> > > Not sure how to interpret this. Morphic is key to OSP, as it is to > OLPC. Are you saying that Morphic will not run on Cuis without > modification, but should it be ported the underlying system is fast > and lean? > > Cuis uses Morphic. Only cleaner, simpler and faster. Why don't you try it for 15 minutes? Cheers, Juan Vuletich |
Seriously, people. TRY IT. Test it out. The differences between Morphic in Squeak/Pharo, and Cuis, are *absolutely* improvements. Juan has sloughed thousands of lines of code. I don't have to work as hard to get a thing done in Cuis, because almost *all* of the bull____ has been cleared away.
Proof of this is that I was able to do the Pareto 20% of what Polymorph did _in ONE class_. And I'm not really that clever. It's undoubtedly the more elegant system I've ever encountered. It might even change the way you think, if you gave it a shot. I dare you: try it. All the love, C:) On Sep 7, 2011, at 5:59 PM, Juan Vuletich <[hidden email]> wrote: > Gary Dunn wrote: >> On Wed, Sep 7, 2011 at 9:27 AM, Casey Ransberger >> <[hidden email]> wrote: >> ... >>> Worth pointing out: applications which use Morphic will take real work to >>> make run over Cuis. Morphic in Cuis is a whole new breed of animal; fast, >>> lean, beautiful, and completely different from the tangle which many >>> applications expect to find down there. >>> >> >> Not sure how to interpret this. Morphic is key to OSP, as it is to >> OLPC. Are you saying that Morphic will not run on Cuis without >> modification, but should it be ported the underlying system is fast >> and lean? >> >> > > Cuis uses Morphic. Only cleaner, simpler and faster. Why don't you try it for 15 minutes? > > Cheers, > Juan Vuletich > |
Administrator
|
In reply to this post by Levente Uzonyi-2
This is pure gold. It would be great to put the personality differences aside (I think the only real obstacle/difference at this point) and unify as much as possible. For sure, another fork would only dilute everyone's great efforts further. But a stack of existing technologies could be very intriguing, if only wishful thinking right now. The seeming current policy of Squeak/Pharo/Cuis/etc to cherry pick changes from the other guys seems to leave little time for killer app development. Imagine something like: cuis - rock-solid, clean, stable, small kernel + pharo - professional-grade Smalltalk with the expected bells and whistles of a modern IDE + squeak - dynabook software (which b.t.w. was the whole point of Squeak - and Smalltalk - in the first place); a medium that unites all other media of human expression, with the required support of PDF reading/writing/viewing, HTML browsing, cross-platform mp3 support... _______________________________________________________________________ = the closest we've ever been to the holy grail of computing (until VPRI releases and makes us all obsolete, lol)
Cheers,
Sean |
In reply to this post by Juan Vuletich-4
On 9/7/11 5:56 PM, Juan Vuletich wrote:
> Levente Uzonyi wrote: We should pick good stuff from Cuis (and Pharo) > instead. [...] >> To make the image smaller we should do two things (in parallel): >> - craving (make packages unloadable, remove dependencies, split >> packages) >> - building (use Spoon to rebuild the current image) > > Growing back the image with Spoon is much easier if you already start > with a clean image, like Cuis. Same for loading packages back: half of > the work is already done. For those who haven't tried it, Juan's Cuis 3.3 image is only 6.5 MB. It would be interesting to see if Craig can use Spoon to make it even more lean. At the other extreme, when Craig brags that he's gotten a minimalist Squeak image to run with only 1337 bytes, he's not joking. I loaded it into a programming text editor (BBEdit) and sure enough, it is exactly 1337 bytes. Very LEET indeed. :-) As far as what makes a "killer app" goes, the answer is obvious. Squeak/Pharo/Cuis/Spoon/Seaside are programming *tools*. This community doesn't have the resources to make a new killer app out of the existing tools (if they did, they'd be multi-millionaires already), BUT, Squeak running on Cog/MTCog is sufficiently fast to compete with other programming environments in order to create THE killer app: tools to create games for others to use to create games. Squeak could easily become the next Flash environment if the APIs existed to manipulate sprites and 3D objects properly. We already have Teatime, which distributes processing in ways that no other platform can even dream of (or even understand without some hours of explanation). Matt Fulmer has managed to get Open Cobalt running in a 4.2 image and play nice with the Morphic GUI (at the cost of some speed, you can overlap windows on top of the OpenGL layer seamlessly http://www.opencobalt.org/downloads). I've been looking at a simple, but fun, 2D game called NAEV. It uses C for the skeleton framework and calls external libraries (most of which Squeak also calls, or has bypassed to some extent) for speed, and uses Lua scripting to bind the game logic together. It uses SDL for its graphics needs -there was a Squeak project to interface with SDL 1.2, but that apparently died when the main programmer did, but I don't think we need SDL interfacing, because we have direct access to the entire OpenGL 1.4 API. Naev is the work of 7 programmers and my impression is that those same programmers using Squeak + OpenGL would have finished their project many months ago, instead of being only halfway through it. What we lack is a wrapper around the various libraries that Squeak already calls that would be attractive to game makers, both 2D and 3D. Combine that with squeak's ease of programming, Teatime, and a way of minimizing the footprint of the image using Cuis & Spoon, and you have something that could attract literally thousands of wannabe game writers to the platform. We have OpenCobalt and OpenQWAK. We need a similar 2D library for sprite-based games as well. Just a thought... L. |
Lawson English wrote:
> ... > For those who haven't tried it, Juan's Cuis 3.3 image is only 6.5 MB. > It would be interesting to see if Craig can use Spoon to make it even > more lean. If you care about image size, http://www.jvuletich.org/Cuis/Cuis3.1r3.zip is about 2Mb. Cheers, Juan Vuletich |
In reply to this post by Juan Vuletich-4
On Wed, Sep 7, 2011 at 2:59 PM, Juan Vuletich <[hidden email]> wrote:
> Gary Dunn wrote: >> >> On Wed, Sep 7, 2011 at 9:27 AM, Casey Ransberger >> <[hidden email]> wrote: >> ... >>> >>> Worth pointing out: applications which use Morphic will take real work to >>> make run over Cuis. Morphic in Cuis is a whole new breed of animal; fast, >>> lean, beautiful, and completely different from the tangle which many >>> applications expect to find down there. >>> >> >> Not sure how to interpret this. Morphic is key to OSP, as it is to >> OLPC. Are you saying that Morphic will not run on Cuis without >> modification, but should it be ported the underlying system is fast >> and lean? >> >> > > Cuis uses Morphic. Only cleaner, simpler and faster. Why don't you try it > for 15 minutes? > > Cheers, > Juan Vuletich Just did. Works fine on FreeBSD 8.2, at least it starts and runs, no exhaustive testing. Right off the bat I checked to see if it would load my Morphic book project. I could not find a way to do that. Then I checked the browser to see if there is a bookmorph. I don't see one, or many of the other Morphic building blocks I use. You can find out more about my book concept here: http://wiki.openslate.net/mediawiki/index.php?title=Chalk_Dust_Applications:Squeak_Projects I agree that there is much that needs fixing in Squeak. I have made several entries in Mantis, for example how the yellow-click pop-up mouse window text formatting commands are broken. And I did try to fix that, and found a dark, confusing swamp filled with tangled code, different code for doing the same task depending on how it is initiated. I knew I was in over my head. Perhaps starting over with Cuis is a good plan. My question is, who is going to do all the work required to port all this good stuff into the new image? When I was in college I lived for awhile in a small, run-down house with two other students. A real Animal House. One day, after a few beers, we decided the place would look a lot better if we painted it. We started in the bathroom, where the paint was really peeling. We stripped the old paint, and stopped. Nobody had the time to devote to finishing the project. -- Gary Dunn Honolulu |
Likely your troubles are in fact with Morphic. It's the spot where the most stuff has changed. Have you tried loading up any of your missing dependencies? I've been able on occasion to get things written for Squeak working without a lot of effort Cuis, but it did take some learning about Cuis' (lovely) flavor of Morphic in order to make things work. Often times, it's just a matter of using a more idiomatic selector where the Squeak code is using (redundant) convenience methods. In other cases, it's really just that Cuis is quite different. It's almost always something to do with Morphic.
If I was you, I'd pick my way through, try to load the stuff that's missing (I often minimize the debugger when I'm loading something and I hit a missing class, that way I don't forget to go back and test it once I've loaded it up.)
If you do this and get stuck, you should post a stack trace or a description of the problem to the list. I'll be glad to help you any way that I can as time allows (though my time is currently up in the air.)
Cheers, Casey
On Thu, Sep 8, 2011 at 3:50 PM, Gary Dunn <[hidden email]> wrote:
Casey Ransberger |
In reply to this post by Casey Ransberger-2
Casey Ransberger wrote:
Inline.An interesting future scenario would be a shared test repository between the various forks of Squeak, with their respective continuous integration servers outputting results to a common database. Differences in "good results " between forks should be catered for, but would highlight differences in the "specification" of each fork, which might help it to converge over time while allowing the implementations to differ. |
On Mon, Sep 12, 2011 at 9:27 AM, Ben Coman <[hidden email]> wrote:
An excellent idea! best, Eliot |
In reply to this post by LawsonEnglish
On Thu, Sep 8, 2011 at 9:29 PM, Lawson English <[hidden email]> wrote:
> On 9/7/11 5:56 PM, Juan Vuletich wrote: >> >> Levente Uzonyi wrote: We should pick good stuff from Cuis (and Pharo) >> instead. > > [...] >>> >>> To make the image smaller we should do two things (in parallel): >>> - craving (make packages unloadable, remove dependencies, split packages) >>> - building (use Spoon to rebuild the current image) >> >> Growing back the image with Spoon is much easier if you already start with >> a clean image, like Cuis. Same for loading packages back: half of the work >> is already done. > > For those who haven't tried it, Juan's Cuis 3.3 image is only 6.5 MB. It > would be interesting to see if Craig can use Spoon to make it even more > lean. > > At the other extreme, when Craig brags that he's gotten a minimalist Squeak > image to run with only 1337 bytes, he's not joking. I loaded it into a > programming text editor (BBEdit) and sure enough, it is exactly 1337 bytes. > Very LEET indeed. :-) > > > As far as what makes a "killer app" goes, the answer is obvious. > Squeak/Pharo/Cuis/Spoon/Seaside are programming *tools*. This community > doesn't have the resources to make a new killer app out of the existing > tools (if they did, they'd be multi-millionaires already), BUT, Squeak > running on Cog/MTCog is sufficiently fast to compete with other programming > environments in order to create THE killer app: tools to create games for > others to use to create games. > > Squeak could easily become the next Flash environment if the APIs existed to > manipulate sprites and 3D objects properly. We already have Teatime, which > distributes processing in ways that no other platform can even dream of (or > even understand without some hours of explanation). Matt Fulmer has managed > to get Open Cobalt running in a 4.2 image and play nice with the Morphic GUI > (at the cost of some speed, you can overlap windows on top of the OpenGL > layer seamlessly http://www.opencobalt.org/downloads). There are lots of "low hanging fruit" that could enhance Squeak for of game development. Tools for managing internal and external resources/ media for example. I would really like to see a lot of game development happening in Squeak :-) Here are a few for fun: http://www.hpi.uni-potsdam.de/hirschfeld/projects/olpc/index.html Karl > > > > I've been looking at a simple, but fun, 2D game called NAEV. It uses C for > the skeleton framework and calls external libraries (most of which Squeak > also calls, or has bypassed to some extent) for speed, and uses Lua > scripting to bind the game logic together. It uses SDL for its graphics > needs -there was a Squeak project to interface with SDL 1.2, but that > apparently died when the main programmer did, but I don't think we need SDL > interfacing, because we have direct access to the entire OpenGL 1.4 API. > Naev is the work of 7 programmers and my impression is that those same > programmers using Squeak + OpenGL would have finished their project many > months ago, instead of being only halfway through it. > > What we lack is a wrapper around the various libraries that Squeak already > calls that would be attractive to game makers, both 2D and 3D. Combine that > with squeak's ease of programming, Teatime, and a way of minimizing the > footprint of the image using Cuis & Spoon, and you have something that could > attract literally thousands of wannabe game writers to the platform. > > We have OpenCobalt and OpenQWAK. We need a similar 2D library for > sprite-based games as well. > > Just a thought... > > > L. > > > > > > |
In reply to this post by LawsonEnglish
Hi-- Lawson writes: > For those who haven't tried it, Juan's Cuis 3.3 image is only 6.5 MB. > It would be interesting to see if Craig can use Spoon to make it even > more lean. No doubt. We could run it through Spoon's "dissolve" feature. It uses an alternate version of the garbage collector to treat as garbage methods which haven't been run since a chosen point in time. It's the most effective way of stripping a system, and it happens in an instant. -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547 |
In reply to this post by Casey Ransberger-2
Hi Casey-- > Craig, if I wanted to try to Spoon-out Cuis, where would I start? Hm, I included the VM changes for Spoon's "dissolve" feature in Spoon 3a3, but not the object-level part. Are you still interested? I could put it somewhere for you. thanks, -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547 |
Free forum by Nabble | Edit this page |