Am 12.06.2013 um 13:12 schrieb LogiqueWerks <grshipl...@gmail.com>: > If it is not under 50Mb with min packages + my classes, then I think no one > in the minimalist camp is going to look at my efforts ( this is my "emit Curl > markup" as alternative-to-HTML project for learning Japanese kanji via > personalized mnemonics. ) > > The first image would be to parse Yaml and emit Curl markup ; the second MAY > use Seaside to respond with MIME of text/vnd.curl ... but I still have so > many issues to address ... and no Xvnc installed yet ... and only Python > 2.6.6 so far on this CentOS 6.3 > > My aversion to PCRE is a driving force here , so I have a lot of work to do … > About what size are you talking? On disk or in memory? I think the smallest usable image you can have at the moment will be around 10MB on disk. This includes the whole IDE, web server etc. Most of the parts will be unloadable in the future. So I would expect an image with some basic functionality in 2MB is a feasible goal (in the not too far future).
In memory it really depends what you are doing. For non-seaside images running on a server the numbers Sven mentioned are good ones. I have an image that is 19MB on disk including Seaside-Rest, XML Parser, Pastell (lightweight xpath queries), RFB (smalltalk VNC server), Fuel (object serializer). I did not clean the image (would probably shrink to 14-15 MB), did not restrict heap size and I didn't optimize memory usage and it has 50MB in memory (RSS). So if size is something that is important for you, you could do the parser - markup generation below 20MB image size if your application isn't wasting a lot of memory. Being on the resource sparing side let me tell you that seaside is not something you want to have. Seaside does mostly server side state for clients. So it collects quite an amount of data per user. I would guess it is even hard to have something below 100MB in memory with a decent number of concurrent sessions. Norbert > > > On 11 June 2013 07:41, Sven Van Caekenberghe-2 [via Smalltalk] <[hidden > email]> wrote: > Robert, > > What size are you aiming for ? > > A normal Pharo image needs between 50 and 100 Mb, with everything included. > > Not much in my book, are there such small VPS machines today ? > I run 6 such Images/VM pairs on a AWS EC2 micro instances (~600Mb RAM). > Linode starts at 1Gb ... > > Sven > > On 11 Jun 2013, at 12:14, LogiqueWerks <[hidden email]> wrote: > > > re: headless Pharo 2.0 > > > > I just finished building gst on a tiny VPS site, but I would rather use > > pharo ... I can get some tips from pharo --help in my SSH console but I > > have > > a big dev CentOS here in VirtualBox in which to experiment in headless > > builds if set on the right track ... > > > > Does anyone have a tip on starting with a Pharo 2.0 core ? I just need > > sockets, minimal HTTP and StdOut - I don't think I want Seaside on this > > tiny > > install ... but I would rather be using an HTTP server in Pharo than in > > Ruby > > or Python ... I have come to loathe Lighttpd and nginx config silliness ... > > but I could fallback to Ruby Sinatra or merb while I wait ... (the > > poor-man's Smalltalk ;-) > > > > Or should I be looking to strip down a VW image and wait for Pharo 3 ? I > > am > > scripting with Rebol 2 for now while I wait for rebol3 or Red ... > > > > thanks, > > Robert > > in a small Atlantic town > > Canada > > > > PS last night I could not see how to run St/X without X to see what mem > > footprint I would face ! > > > > > > > > -- > > View this message in context: > > http://forum.world.st/minimal-headless-pharo2-for-CentOS-tp4692753.html > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > > If you reply to this email, your message will be added to the discussion > below: > http://forum.world.st/minimal-headless-pharo2-for-CentOS-tp4692753p4692755.html > To unsubscribe from minimal headless pharo2 for CentOS, click here. > NAML > > > View this message in context: Re: minimal headless pharo2 for CentOS > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
