October 2013 - Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

On Oct 3, 2013, at 1:44 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > 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. It does. But I want more :) I want a comment that explain to me the purpose. > > > HTH, > Eliot

Oct. 3, 2013

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

by Goubier Thierry

Then for smart suggestions, pragma AST nodes should have an 'implementorsOf' and 'references' commands on them :) Thierry Le 03/10/2013 01:44, Eliot Miranda a Ã©crit : > On Wed, Oct 2, 2013 at 11:34 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@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 -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Oct. 3, 2013

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

by Miguel Moquillon

+100 Miguel Le 03/10/2013 01:44, Eliot Miranda a Ã©crit : > On Wed, Oct 2, 2013 at 11:34 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@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. 3, 2013

Re: [Pharo-dev] about configuration to manage the image

by Marcus Denker

On Oct 2, 2013, at 10:20 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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. > e.g. the compiler changes where cross cutting both the compiler package and the e.g. AST. Or the Compiler and the Kernelâ¦ Marcus

Oct. 3, 2013

New project announcement: PROXimity

by Olivier Auverlot

Hi, I just started since 3 days to work on a new framework for Pharo. It's named "PROXimity". The goal of this framework is to control a Proxmox virtualization solution with Pharo. Proxmox uses a REST API. With Zinc and STON, it's very easy to give orders as creating a virtual machine, managing the boot and stop, etc. I'm working on this project because it is a subpart of another application but I think that it could interest other Pharo users (for example: seaside hosting). The first Pharo classes are published on SmalltalkHub. If you're interested and want join your forces with me, don't hesitate to contact me. http://www.proxmox.com http://pve.proxmox.com/wiki/Proxmox_VE_API Best regards Olivier ;-)

Oct. 3, 2013

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