- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo (cog) Vm on Windows with 2GB virtual mem

by Oscar EA CallaÃº

Thanks, but what would be the parameter? This is the default .ini [Global] DeferUpdate=1 ShowConsole=0 DynamicConsole=1 ReduceCPUUsage=1 ReduceCPUInBackground=0 3ButtonMouse=0 1ButtonMouse=0 UseDirectSound=1 PriorityBoost=1 B3DXUsesOpenGL=0 CaseSensitiveFileMode=0 So there is no mention the paratemer to change or add. Cheers. From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Guillermo Polito Sent: Friday, September 27, 2013 5:18 AM To: Pharo Development List Subject: Re: [Pharo-dev] Pharo (cog) Vm on Windows with 2GB virtual mem I think latest Pharo VM supports to change the memory limit by only changing an ini file. Igor did that not long ago. Cheers, Guille On Fri, Sep 27, 2013 at 2:09 PM, Oscar E. A. CallaÃº <oalvarez(a)dcc.uchile.cl <mailto:oalvarez@dcc.uchile.cl> > wrote: Hi Guys, I read in this thread http://forum.world.st/out-of-memory-cog-on-windows-td3465621.html that 512 mb limit can be avoided in windows, but a re-compilation is needed. I was wondering if the situation changed, and now we can pass a parameter. Otherwise, I would be interested if any of you has a pre-compiled vm with more mem. I need to run some experiments and I need 2GB (or 1.5 GB at least ) on a cog VM for Windows. Thanks in advance. Oscar

Oct. 3, 2013

Re: [Pharo-dev] Could we have a list of the official pragmas because it starts to be a MESS!

by Eliot Miranda

On Wed, Oct 2, 2013 at 11:34 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > For example > > <systemEventRegistration> > I have no idea (of course there is no comment) what is the use of > this pragma. > > Chasing pragma interpreter can be painful so we should pay attention. > Too many pragmas are a plague. > Agreed. Part of the design of pragmas is that, because they're message sends, they have implementations. Those implementations can document what the pragma does. The browser should include pragma selectors when doing "implementors..." so one can easily find the implementation of a pragma. Also senders... should answer methods with pragmas with the selector being looked for. If both of these are true then pragmas are much easier to explore and understand. HTH, Eliot

Oct. 2, 2013

[ANN] Bootstrap for Seaside3 project (Release 0.1.0)

by Torsten Bergmann

Hi, there are various frameworks out there helping you to ease common tasks in web development. One of them is Bootstrap (http://getbootstrap.com) that is used more and more to easily style web sites and web applications. We had wrappers for Bootstrap supporting Seaside in the past already: - the TwitterBootstrap project on SS3 from the Seaside team - the TBootstrap project from Gaston Dall Oglio Unfortunately these projects are not up to date with the latest Bootstrap version, not covered by tests, had no docu or examples, no CI, ... To provide better support for Bootstrap and Seaside3 development I created a fresh project called "Bootstrap for Seaside" (or "Bootstrap" for short). This new project is - nearly feature complete regarding components (Nav, Navbar, Jumbotron, Buttons, Alarms, Layouts, ...) - uses the latest Bootstrap libraries (http://getbootstrap.com) - covered by more than 160 tests - completed with an example browser that shows Bootstrap components and according Smalltalk code - available at STHub (http://smalltalkhub.com/#!/~TorstenBergmann/Bootstrap) - documented (see mentioned project website on STHub) with docu support for PharoOnlineHelp and catalog - controlled by CI (https://ci.inria.fr/pharo-contribution/job/Bootstrap/) - easily loadable using config browser in Pharo 2.0 Attached are some screenshots from the project itself. More details can be found in the more docu at the project site on SmalltalkHub. Just scroll down at the info page provided there. You can easily load it in a fresh Pharo 2.0 as "Bootstrap" from the config browser. It loads Seaside3 as a dependency. After loading evaluate ZnZincServerAdaptor startOn: 8080 to start the webserver and go to http://localhost:8080/bootstrap to browse the samples. Feel free to use it for your next Pharo/Seaside/Bootstrap based web project and thanks in advance for any contribution you may give to the project in the future. Bye T.

Oct. 2, 2013

FOSDEM devroom

by Stephan Eggermont

The FOSDEM organisation has accepted a devroom proposal for all smalltalk and related projects. Please let me know what you'd like to see there, and what you'd like to show. It will be one day in the weekend of 1-2 february in Brussels https://fosdem.org/2014/ Cheers, Stephan

Oct. 2, 2013

Re: [Pharo-dev] Glorp, Fuel, Native postgres driver, Voyage/Mongo, any in GemStone?

by Mariano Martinez Peck

On Wed, Oct 2, 2013 at 5:29 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Oct 2, 2013, at 10:24 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > > On Wed, Oct 2, 2013 at 5:13 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Mariano >> >> why 1Gb and not tomorrow afternoon 5 Gb and in two days 10 Gb? >> > > Yes, it will probably be like this. But by then time I use 5GB my server > will probably have 100GB by then. > > > Indeed so you will have to find a real solution to manage your data and > having a large database in memory may not be the way to go. > > Yes, I will probably need quite a lot of data in memory for a very particular use-cases. Still, notice still 5GB or 10GB is way less than my server, which has 32GB. > > >> Of course Pharo is limited and I hope that with the new Cog >> > > Indeed, I hope it too. And yes, it seems this will change with what Eliot > is doing. > > >> it will be different but soon it will not fit in the ram of your OS. >> >> Stef >> >> >> >> On Wed, Oct 2, 2013 at 4:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: >> >>> Mariano, >>> >>> On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck(a)gmail.com> >>> wrote: >>> >>> > Hi guys. >>> > First, let me apologize for the amount of emails I am sending. I am >>> doing an analysis to see if GemStone is a good candidate for a project I am >>> working and so it deserves some research. >>> > >>> > I wondered if any has ever tried porting any of these tools to >>> GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB. >>> >>> I do not understand. >>> >>> IMHO there is only one reason to go to Gemstone, and that is to use its >>> capabilities as OODB. All the technologies you mention are persistency >>> related and would not be needed in that case, right ? >>> >> >> More or less. Fuel would be awesome to move data between Pharo and >> GemStone. SIXX has demonstrated some limitations. >> And regarding Glorp / native postgres driver and Voyage/Mongo is because >> what I may store in GemStone is not the only DB in the game. I may have >> OTHER DBs that for a reason not important here, should remain either in a >> relation DB or in Voyage. Yet, I need to query them somehow from Pharo. Of >> course, I can have a Pharo image that does the job and provides >> web-services (or anything similar) to my GemStone....but of course it is >> easier if these DB clients would work in GemStone as well.... >> >> >>> >>> As you most probably know, you can get pretty far with Pharo. >> >> >> Yes I know. But this particular application may have a lot of data >> processing, algorithms, etc, which may probably NOT fit in 1GB of memory >> and the effort to distribute the process among multiple images could be >> high. >> >> >>> After that, there is load-balancing, partitioning, message queues. >>> Pretty much what any technology stack does. >>> >>> >> Indeed. But I would still need a persistency solution that satisfy all my >> needs. I should write this down and compare the alternatives in Pharo. >> >> >>> You will always find more tools and libraries on the Pharo side, as the >>> community is much larger. >>> >>> >> Sure. But at least I would only miss the "deployment" libraries, since in >> any case I will continue developing in Pharo, so all the development tools >> and all the environment will be the same. >> >> >> Thanks for the discussion! >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Oct. 2, 2013

reloading with green tests RB in Pharo 3.0

by StÃ©phane Ducasse

Using a new and clean configuration I can reload RB (critics, environment, core/changes) I hope to get the time to reload Nautilus and atfter the others. I really think that we will need to be able to execute unload and postLoad action (we can already). I wonder if I will be able to do it for KeyMapping for example. We will see. Stef

Oct. 2, 2013

Re: [Pharo-dev] Glorp, Fuel, Native postgres driver, Voyage/Mongo, any in GemStone?

by StÃ©phane Ducasse

On Oct 2, 2013, at 10:24 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Wed, Oct 2, 2013 at 5:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Mariano > > why 1Gb and not tomorrow afternoon 5 Gb and in two days 10 Gb? > > Yes, it will probably be like this. But by then time I use 5GB my server will probably have 100GB by then. Indeed so you will have to find a real solution to manage your data and having a large database in memory may not be the way to go. > > Of course Pharo is limited and I hope that with the new Cog > > Indeed, I hope it too. And yes, it seems this will change with what Eliot is doing. > > it will be different but soon it will not fit in the ram of your OS. > > Stef > > > >> On Wed, Oct 2, 2013 at 4:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Mariano, >> >> On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> > Hi guys. >> > First, let me apologize for the amount of emails I am sending. I am doing an analysis to see if GemStone is a good candidate for a project I am working and so it deserves some research. >> > >> > I wondered if any has ever tried porting any of these tools to GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB. >> >> I do not understand. >> >> IMHO there is only one reason to go to Gemstone, and that is to use its capabilities as OODB. All the technologies you mention are persistency related and would not be needed in that case, right ? >> >> More or less. Fuel would be awesome to move data between Pharo and GemStone. SIXX has demonstrated some limitations. >> And regarding Glorp / native postgres driver and Voyage/Mongo is because what I may store in GemStone is not the only DB in the game. I may have OTHER DBs that for a reason not important here, should remain either in a relation DB or in Voyage. Yet, I need to query them somehow from Pharo. Of course, I can have a Pharo image that does the job and provides web-services (or anything similar) to my GemStone....but of course it is easier if these DB clients would work in GemStone as well.... >> >> >> As you most probably know, you can get pretty far with Pharo. >> >> Yes I know. But this particular application may have a lot of data processing, algorithms, etc, which may probably NOT fit in 1GB of memory and the effort to distribute the process among multiple images could be high. >> >> After that, there is load-balancing, partitioning, message queues. Pretty much what any technology stack does. >> >> >> Indeed. But I would still need a persistency solution that satisfy all my needs. I should write this down and compare the alternatives in Pharo. >> >> You will always find more tools and libraries on the Pharo side, as the community is much larger. >> >> >> Sure. But at least I would only miss the "deployment" libraries, since in any case I will continue developing in Pharo, so all the development tools and all the environment will be the same. >> >> >> Thanks for the discussion! >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com

Oct. 2, 2013

Re: [Pharo-dev] Glorp, Fuel, Native postgres driver, Voyage/Mongo, any in GemStone?

by Mariano Martinez Peck

On Wed, Oct 2, 2013 at 5:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Mariano > > why 1Gb and not tomorrow afternoon 5 Gb and in two days 10 Gb? > Yes, it will probably be like this. But by then time I use 5GB my server will probably have 100GB by then. > Of course Pharo is limited and I hope that with the new Cog > Indeed, I hope it too. And yes, it seems this will change with what Eliot is doing. > it will be different but soon it will not fit in the ram of your OS. > > Stef > > > > On Wed, Oct 2, 2013 at 4:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > >> Mariano, >> >> On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> >> > Hi guys. >> > First, let me apologize for the amount of emails I am sending. I am >> doing an analysis to see if GemStone is a good candidate for a project I am >> working and so it deserves some research. >> > >> > I wondered if any has ever tried porting any of these tools to >> GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB. >> >> I do not understand. >> >> IMHO there is only one reason to go to Gemstone, and that is to use its >> capabilities as OODB. All the technologies you mention are persistency >> related and would not be needed in that case, right ? >> > > More or less. Fuel would be awesome to move data between Pharo and > GemStone. SIXX has demonstrated some limitations. > And regarding Glorp / native postgres driver and Voyage/Mongo is because > what I may store in GemStone is not the only DB in the game. I may have > OTHER DBs that for a reason not important here, should remain either in a > relation DB or in Voyage. Yet, I need to query them somehow from Pharo. Of > course, I can have a Pharo image that does the job and provides > web-services (or anything similar) to my GemStone....but of course it is > easier if these DB clients would work in GemStone as well.... > > >> >> As you most probably know, you can get pretty far with Pharo. > > > Yes I know. But this particular application may have a lot of data > processing, algorithms, etc, which may probably NOT fit in 1GB of memory > and the effort to distribute the process among multiple images could be > high. > > >> After that, there is load-balancing, partitioning, message queues. Pretty >> much what any technology stack does. >> >> > Indeed. But I would still need a persistency solution that satisfy all my > needs. I should write this down and compare the alternatives in Pharo. > > >> You will always find more tools and libraries on the Pharo side, as the >> community is much larger. >> >> > Sure. But at least I would only miss the "deployment" libraries, since in > any case I will continue developing in Pharo, so all the development tools > and all the environment will be the same. > > > Thanks for the discussion! > > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Oct. 2, 2013

about configuration to manage the image

by StÃ©phane Ducasse

Now I redid the configuration of Refactoring and Critics and publish the new package in the correct repository (ok marcus you did it so this is great but it will not scale) because there was a new changes touching all the packages. So this was a bad idea from me. => for now no separate repository => no move of package in between => I suggest that we load in the image the configuration and probably the process should manipulate configurations (I did not want to touch the metacello toolbox), I think that I will lose days thereâ¦. Or we simply gave up with the idea to have an image that can be modular. So we have to think and get smart. Stef

Oct. 2, 2013

Re: [Pharo-dev] Glorp, Fuel, Native postgres driver, Voyage/Mongo, any in GemStone?

by StÃ©phane Ducasse

Mariano why 1Gb and not tomorrow afternoon 5 Gb and in two days 10 Gb? Of course Pharo is limited and I hope that with the new Cog it will be different but soon it will not fit in the ram of your OS. Stef > On Wed, Oct 2, 2013 at 4:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Mariano, > > On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > Hi guys. > > First, let me apologize for the amount of emails I am sending. I am doing an analysis to see if GemStone is a good candidate for a project I am working and so it deserves some research. > > > > I wondered if any has ever tried porting any of these tools to GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB. > > I do not understand. > > IMHO there is only one reason to go to Gemstone, and that is to use its capabilities as OODB. All the technologies you mention are persistency related and would not be needed in that case, right ? > > More or less. Fuel would be awesome to move data between Pharo and GemStone. SIXX has demonstrated some limitations. > And regarding Glorp / native postgres driver and Voyage/Mongo is because what I may store in GemStone is not the only DB in the game. I may have OTHER DBs that for a reason not important here, should remain either in a relation DB or in Voyage. Yet, I need to query them somehow from Pharo. Of course, I can have a Pharo image that does the job and provides web-services (or anything similar) to my GemStone....but of course it is easier if these DB clients would work in GemStone as well.... > > > As you most probably know, you can get pretty far with Pharo. > > Yes I know. But this particular application may have a lot of data processing, algorithms, etc, which may probably NOT fit in 1GB of memory and the effort to distribute the process among multiple images could be high. > > After that, there is load-balancing, partitioning, message queues. Pretty much what any technology stack does. > > > Indeed. But I would still need a persistency solution that satisfy all my needs. I should write this down and compare the alternatives in Pharo. > > You will always find more tools and libraries on the Pharo side, as the community is much larger. > > > Sure. But at least I would only miss the "deployment" libraries, since in any case I will continue developing in Pharo, so all the development tools and all the environment will be the same. > > > Thanks for the discussion! > > > > -- > Mariano > http://marianopeck.wordpress.com

Oct. 2, 2013