March 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3339 in pharo: WeakOrderedCollection

by Miguel CobÃ¡

thanks! El mar, 22-03-2011 a las 13:25 +0000, pharo(a)googlecode.com escribiÃ³: > Updates: > Status: Closed > > Comment #1 on issue 3339 by marcus.d...(a)gmail.com: WeakOrderedCollection > http://code.google.com/p/pharo/issues/detail?id=3339 > > We added it > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

March 22, 2011

Re: [Pharo-project] Issue 3843 in pharo: isHealthy for HasedCollection

by pharo＠googlecode.com

Comment #2 on issue 3843 by ryd...(a)gmail.com: isHealthy for HasedCollection http://code.google.com/p/pharo/issues/detail?id=3843 We have unhealthy ones? Where is the method?

March 22, 2011

Re: [Pharo-project] Do you have a tool that works on Pharo ?

by Mariano Martinez Peck

Thanks Graig, and thanks to all who have asked me a user to edit ;) On Tue, Mar 22, 2011 at 3:29 PM, Craig Latta <craig(a)netjam.org> wrote: > > Hi Mariano-- > > > Chronos > > I mentioned your note to Alan Lovejoy, the developer of Chronos (a > Date/Time library, see http://chronos-st.org ). > > > -C > > -- > Craig Latta > www.netjam.org/resume > +31 06 2757 7177 > + 1 415 287 3547 > > > > >

March 22, 2011

Re: [Pharo-project] Pharo 2010 - Thank you!

by Dario Trussardi

Dear Stef, and All i'm ready to work for development a small ERP. How i write some time ago i think to do it with a platform based on: A) Magritte description to define the meta database B) Seaside web interface as user interface C) Gemstone (GLASS) to "store" object You write about Suixo framework. How i can understand about it ? Anyone have a good idea about the setup platform - framework and ...... ? Any pointers would be greatly appreciated ! Dario > Context > Suixo is an open source Smalltalk Seaside application framework used to build a.o. a vertical market solution for healthcare. The healthcare solution is currently used daily by about 80 users. Suixo is an application level framework and currently features: > > â¢ Workflow engine > â¢ Generic party model (company / person) > â¢ Role based access control > â¢ Time tracking > â¢ Content management system > > So I was wrong. > > > > On Dec 24, 2010, at 10:19 AM, Dario Trussardi wrote: > >> Dear Stef >> >>> dario did you look at (I always forget the name) suiza? >>> Because this is a start of that? >>> >> >> I don't understand your reference. >> >> What is suiza ? >> >> Can you add some information about it ? >> >> >>> Stef >>> >>> >>>> +1 >>>> >>>> Good Christmas to you and your family. >>>> >>>> >>>> About: >>>> >>>> do you think that a good open-source ERP in Smalltalk would help you? >>>> >>>> >>>> I'm interesting to ERP in Smalltalk. >>>> >>>> I think it with: >>>> >>>> - Seaside interface >>>> >>>> - Gemstone OODB ( GLASS ) >>>> >>>> - Magritte for meta data base description >>>> >>>> >>>> Ciao, >>>> >>>> Dario >>>> >>> >> >> Thank, >> >> Dario >> > >

March 22, 2011

Re: [Pharo-project] test crashing the cog vm

by Alexandre Bergel

I tried to have a look at SchemeTalk. Apparently the website is not up to date. I reached http://www.iam.unibe.ch/~verwaest/blog/?p=6 from http://scg.unibe.ch/research/schemetalk Alexandre On 22 Mar 2011, at 11:16, Toon Verwaest wrote: > On 03/22/2011 05:10 PM, Alexandre Bergel wrote: >> I see your point and I suspected you spoke according to your experience. I am just trying to make people innovate, in my own way. >> >> Another thing. Keeping the VM small will definitely help when moving to a different executing platform. It would be amazing to have the Pharo running on Javascript VM. > That's not even that hard. I even had Pharo running on top of my own SchemeTalk already, after 2 days of hacking. I only stopped where I bumped into traits, since I didn't find any bootstrapping script for traits. > > I would basically compile all the smalltalk code to equivalent schemetalk code (very easy since the models are very similar), and compile all the natives to function-calls that perform what the native should perform. These functions had names that wouldn't clash with the Smalltalk names so you couldn't refer to it directly. > > Obviously in the end you would have all the smalltalk code running with SchemeTalk syntax, but all the code was virgin Pharo code. Very fun stuff :) > And if you do it this way, it doesn't really depend on your VM anyway, since I was executing Smalltalk code as Scheme code, not as Smalltalk bytecodes interpreted by schemecode. That's a lot faster. > > cheers, > Toon >> Alexandre >> >> >>> Ok, I very much understand this point of view. That's exactly why I started Pinocchio. >>> >>> I'm currently building my 4rd iteration. I started building a Smalltalk by having AST evaluation (actually I started out with self-evaluating AST objects that got evaluated by sending message... :D) . Then moved on to stack-based bytecodes. Then moved on to registered-based bytecodes (where I am now). All of my progress has been made by careful scrutinizing of the problems at hand. I did reevaluate and question all steps; and I'm a bit sad that I ended up doing it this way... But then I guess there is some inevitability in it. >>> >>> For example the register-based bytecodes, I had no idea that what I was doing were register-based bytecodes until I read the Lua VM description and noticed that it was exactly the same. >>> >>> However I do think that I learned a lot by doing it. I made the trade-offs myself and understand them a lot better than I did before. What I'm defending in this discussion isn't based on estimates but experience from building it from the ground up. >>> >>> And this is where I welcome everyone to do the same! It took me 2 years to get to where I am now, but maybe it goes faster for you ;) It is definitely a very worthwhile exercise. And I think because of it I'm finally at the point where I can contribute something... >>> >>> cheers, >>> Toon >>> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 22, 2011

Re: [Pharo-project] Inspector in 1.2

by AxiNat

Thanks again, that fixed it :) 2011/3/22 Esteban Lorenzano <estebanlm(a)gmail.com> > yes... that's because NewInspector has it's own tool set. > I worked around by making NewInspectorToolSet inherits from DEVToolSet. > > best, > Esteban > > El 22/03/2011, a las 12:59p.m., AxiNat escribiÃ³: > > Is it possible that installing the NewInspector has broken the > autocompleter and some other stuff? > > 2011/3/22 AxiNat <tibabenfortlapalanca(a)gmail.com> > >> Thanks a lot, I do value them :) >> >> >> 2011/3/22 Henrik Johansen <henrik.s.johansen(a)veloxit.no> >> >>> >>> On Mar 22, 2011, at 3:45 28PM, AxiNat wrote: >>> >>> > Hi list, >>> > >>> > First of all, I'd like to apologise just in case this is already a >>> known issue; I checked and couldn't find it around. >>> > >>> > I've started working with 1.2 RC a couple days ago, and I noticed the >>> inspector went back to (IIRC) several releases ago. In 1.1 we had tree >>> navigation and were able to run code in context, now you must open a new >>> inspector for each node and the code is always executed from the scope of >>> the root object. I've also noticed you can't remove items from a collection >>> straight from the UI anymore. >>> > >>> > Thanks! >>> > >>> > Bernat Romagosa. >>> >>> >>> The reason it's not included by standard any more I believe has mostly to >>> do with its performance when handling large collections. >>> If you value its features over its faults like some other here, it is >>> still loadable as an external tool, see: >>> ConfigurationOfNewInspector in the MetacelloRepository. >>> >>> Cheers, >>> Henry >>> >>> >>> >>> >> > >

March 22, 2011

Re: [Pharo-project] test crashing the cog vm

by Alexandre Bergel

I see your point and I suspected you spoke according to your experience. I am just trying to make people innovate, in my own way. Another thing. Keeping the VM small will definitely help when moving to a different executing platform. It would be amazing to have the Pharo running on Javascript VM. Alexandre > Ok, I very much understand this point of view. That's exactly why I started Pinocchio. > > I'm currently building my 4rd iteration. I started building a Smalltalk by having AST evaluation (actually I started out with self-evaluating AST objects that got evaluated by sending message... :D) . Then moved on to stack-based bytecodes. Then moved on to registered-based bytecodes (where I am now). All of my progress has been made by careful scrutinizing of the problems at hand. I did reevaluate and question all steps; and I'm a bit sad that I ended up doing it this way... But then I guess there is some inevitability in it. > > For example the register-based bytecodes, I had no idea that what I was doing were register-based bytecodes until I read the Lua VM description and noticed that it was exactly the same. > > However I do think that I learned a lot by doing it. I made the trade-offs myself and understand them a lot better than I did before. What I'm defending in this discussion isn't based on estimates but experience from building it from the ground up. > > And this is where I welcome everyone to do the same! It took me 2 years to get to where I am now, but maybe it goes faster for you ;) It is definitely a very worthwhile exercise. And I think because of it I'm finally at the point where I can contribute something... > > cheers, > Toon > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 22, 2011

Re: [Pharo-project] Inspector in 1.2

by Esteban Lorenzano

yes... that's because NewInspector has it's own tool set. I worked around by making NewInspectorToolSet inherits from DEVToolSet. best, Esteban El 22/03/2011, a las 12:59p.m., AxiNat escribiÃ³: > Is it possible that installing the NewInspector has broken the autocompleter and some other stuff? > > 2011/3/22 AxiNat <tibabenfortlapalanca(a)gmail.com> > Thanks a lot, I do value them :) > > > 2011/3/22 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > > On Mar 22, 2011, at 3:45 28PM, AxiNat wrote: > > > Hi list, > > > > First of all, I'd like to apologise just in case this is already a known issue; I checked and couldn't find it around. > > > > I've started working with 1.2 RC a couple days ago, and I noticed the inspector went back to (IIRC) several releases ago. In 1.1 we had tree navigation and were able to run code in context, now you must open a new inspector for each node and the code is always executed from the scope of the root object. I've also noticed you can't remove items from a collection straight from the UI anymore. > > > > Thanks! > > > > Bernat Romagosa. > > > The reason it's not included by standard any more I believe has mostly to do with its performance when handling large collections. > If you value its features over its faults like some other here, it is still loadable as an external tool, see: > ConfigurationOfNewInspector in the MetacelloRepository. > > Cheers, > Henry > > > > >

March 22, 2011

Re: [Pharo-project] Inspector in 1.2

by AxiNat

Is it possible that installing the NewInspector has broken the autocompleter and some other stuff? 2011/3/22 AxiNat <tibabenfortlapalanca(a)gmail.com> > Thanks a lot, I do value them :) > > > 2011/3/22 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > >> >> On Mar 22, 2011, at 3:45 28PM, AxiNat wrote: >> >> > Hi list, >> > >> > First of all, I'd like to apologise just in case this is already a known >> issue; I checked and couldn't find it around. >> > >> > I've started working with 1.2 RC a couple days ago, and I noticed the >> inspector went back to (IIRC) several releases ago. In 1.1 we had tree >> navigation and were able to run code in context, now you must open a new >> inspector for each node and the code is always executed from the scope of >> the root object. I've also noticed you can't remove items from a collection >> straight from the UI anymore. >> > >> > Thanks! >> > >> > Bernat Romagosa. >> >> >> The reason it's not included by standard any more I believe has mostly to >> do with its performance when handling large collections. >> If you value its features over its faults like some other here, it is >> still loadable as an external tool, see: >> ConfigurationOfNewInspector in the MetacelloRepository. >> >> Cheers, >> Henry >> >> >> >> >

March 22, 2011

Re: [Pharo-project] test crashing the cog vm

by Alexandre Bergel

>> I am not saying that this is feasible with the current VM. But I am doubtful that the bytecode verification can only be done in the VM. If something get wrong, why not to raise a primitiveFailed, as 1/0 will do? >> > Because checking all these things at runtime will make interpretation slow. But could not it be at compile time? I am not expert in VM. But something that I learnt from all over these years, is that if we copy what other people do, then we will just have a pale copy. Innovation begins by doing what other think it is impossible to do. Smalltalk has classes as object, whereas Java and C++ took a different stance. Smalltalk has the debugger and the profiler in the image; again, java people have a different opinion. Now, if someone say that bytecode verification can only be done in the VM, I am skeptic. >> You could have the necessary guards in the VM. > > Slow. I do not know. There are guards for arrays, message sent, primitive calls, ... And it is not that slow. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 22, 2011