- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3684 in pharo: primitive: 'primitiveDirectoryLookup' module: 'FilePlugin' returns wrong creation date

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3684 by marcus.d...(a)gmail.com: primitive: 'primitiveDirectoryLookup' module: 'FilePlugin' returns wrong creation date http://code.google.com/p/pharo/issues/detail?id=3684 move to cog tracker http://code.google.com/p/cog/issues/detail?id=12

March 22, 2011

Re: [Pharo-project] [OT] GTK3 directions - what about Morphic ?

by laurent laffont

Little update: http://www.osnews.com/story/24536/Gtk_3_2_Runs_Any_Gtk_Application_in_a_Bro… <http://www.osnews.com/story/24536/Gtk_3_2_Runs_Any_Gtk_Application_in_a_Bro…> Laurent On Wed, Mar 16, 2011 at 11:09 AM, laurent laffont <laurent.laffont(a)gmail.com > wrote: > Hi, > > I've seen: > - you can style GTK3 with CSS: > http://gnomejournal.org/article/107/styling-gtk-with-css > - GTK3 apps can be rendered in a web browser: > http://blogs.gnome.org/alexl/2010/11/23/gtk3-vs-html5/ > > This sounds sexy. > > I wonder how hard it would be to have SimpleMorphic go in this direction. > And whether this is useful or not. > > Laurent. >

March 22, 2011

Re: [Pharo-project] Issue 3667 in pharo: ThreadSafeTranscript does not understand crtab and crtab:

by pharo＠googlecode.com

Updates: Status: FixProposed Labels: Milestone-1.3 Comment #2 on issue 3667 by marcus.d...(a)gmail.com: ThreadSafeTranscript does not understand crtab and crtab: http://code.google.com/p/pharo/issues/detail?id=3667 fix attached Attachments: FixTranscript.1.cs 406 bytes

March 22, 2011

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

by Toon Verwaest

It's a very simple idea really. Where your bytecode would previously look like pushTemp: 1 pushTemp: 2 add now it looks like: add 1, 2, 3 where 3 is the start of your original stack, for example. So rather than pushing and popping etc, you just abstractly interpret the bytecodes and figure out the stack locations where they would be pushed. And then you use this number as arguments to a copy bytecode, rather than calling "push". This avoids having to maintain a stack where you up front already know what the target index will be. You know this up front since your code is static by itself. The advantage is that you don't need to do stack-tricks to keep data around, since all the operation are simple things such as copy, loadFromOuterScope, storeInOuterScope, loadFromField, storeInField, ... So conversely to what you might have thought beforehand, you don't have "real registers" around, you just consider a stackframe to be a set of registers. And you operate on them with easy bytecodes. The advantage, in addition to it being less work and thus slightly faster by itself, is that it will later on also map better on the real hardware. The operations already look like what normal assembler operations would look like. cheers, Toon On 03/22/2011 07:00 PM, StÃ©phane Ducasse wrote: > Can you explain rapidly register-case byte code? > > Stef > > On Mar 22, 2011, at 4:02 PM, Toon Verwaest wrote: > >> On 03/22/2011 04:52 PM, Alexandre Bergel wrote: >>>>> 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. >> 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 >> >

March 22, 2011

Re: [Pharo-project] Getting a functionning unstable image

by Nicolas Cellier

2011/3/22 Igor Stasenko <siguctua(a)gmail.com>: > On 22 March 2011 13:28, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Mar 22, 2011, at 1:25 PM, StÃ©phane Ducasse wrote: >> >>> +1 >>> >>> Now condenses change should work too :) >>> >> >> I am slowly adopting a radical "if we don't test it, it's will brake" point of view. >> I now even say: If we don't test it, it *should* be broken! Because it is dead >> code and should be removed. >> > > I like a systematic approach. :) > Agree, If not maintained it won't work. If not tested it's not maintained. So your sentence must be true in most cases (except case of luck) And if not maintained, the choices are - revive - or remove and that is the Pharo way, Squeak being more conservative. Nicolas >> Â Â Â Â Marcus >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

March 22, 2011

Re: [Pharo-project] in 13101 it looks like I broke the toolbar. I need help

by StÃ©phane Ducasse

apparently this was only in my image. Strange On Mar 22, 2011, at 4:46 PM, StÃ©phane Ducasse wrote: > hi guys > > can you have a look. Apparently the tool bar does not receive event. > > Stef >

March 22, 2011

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

by StÃ©phane Ducasse

It depends what you want to get from a bytecode verifier. May be with a sealing semantics at package level (compiledMethod that can only be created once...) or something like that you could get the code loaded, the package verified and installed without having to make the vm more complex. Stef

March 22, 2011

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

by StÃ©phane Ducasse

Can you explain rapidly register-case byte code? Stef On Mar 22, 2011, at 4:02 PM, Toon Verwaest wrote: > On 03/22/2011 04:52 PM, Alexandre Bergel wrote: >>>> 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. > 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 >

March 22, 2011

Re: [Pharo-project] Filesystem and FS extensions in Pharo book

by StÃ©phane Ducasse

Max if you want to help what you can do is to have a look at the Filesystem chapter in the pharo by example vol 2 on github. We will update it and probably should do several passes on the chapter anyway. Stef > Yes, I understand that. My question is if I should create entries for the "old" version since that one is working and has working extensions. > > Max > > > On 22.03.2011, at 13:37, StÃ©phane Ducasse wrote: > >> right now we are stuck because we started documenting and understanding FS and coling publihsed a new one and he should merge our changes >> >> Stef >> >> On Mar 22, 2011, at 1:20 PM, Max Leske wrote: >> >>> Hey >>> >>> I miss Filesystem and its extensions (cURL, zip, git etc.) in the Pharo book. I'd write the entries but I want your oppinion on whether we should wait till the Filesystem rewrite in 1.2 is ready. >>> >>> My suggestion: >>> >>> ---- Pharo Tools >>> ---- ---- Filesystem >>> ---- ---- ---- Filesystem for Pharo 1.1 >>> ---- ---- ---- ---- extensions 1 ...n >>> ---- ---- ---- Filesystem for Pharo 1.2 >>> ---- ---- ---- ---- extensions 1 ...n >>> >>> Should we even list the "old" versions? The downside to that is that we would have to wait for all the extensions to be updated. >>> What do you think? >>> >>> Max >>> >>> >> >> > >

March 22, 2011

[Pharo-project] About Suixo

by StÃ©phane Ducasse

Excellent contact stefan eggermont. Stef On Mar 22, 2011, at 5:23 PM, Dario Trussardi wrote: > > 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