April 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Tirade!

by GÃ¶ran Krampe

Ok, I spent some time adding support for literal arrays to Tirade. It probably has bugs and I haven't written tests for them but it does parse this correctly: (TiradeParser parse: 'keyword: #(1 -2 3.4 -4.5 ''asd'' (2 nil true false 3) #jupp jupp jupp:tup: #''ju li'' jup:tu 2).') last value first ...produces this: #(1 -2 3.4 -4.5 'asd' #(2 nil true false 3) #jupp #jupp #jupp:tup: #'ju li' #'jup:tu' 2) So it handles integers, floats, nil, true, false, nested literal arrays and symbols. In fact it does handle some more than a true literal array does since Tirade supports { bla . bla } arrays also (but only of literals) and also treats key -> value as a literal syntax. Thus for example these work too: (TiradeParser parse: 'keyword: #(1->2 3->#ad).') last value first (TiradeParser parse: 'keyword: #({2 . 4}).') last value first regards, GÃ¶ran

April 24, 2012

[Pharo-project] Native Boost plugin pour Athens

by StÃ©phane Ducasse

> Stephane > > Le 24 avril 2012 12:32, stephane ducasse <stephane.ducasse(a)gmail.com> a Ã©crit : >> il faut la VM qui accepte nativeBoost. >> https://ci.lille.inria.fr/pharo/view/NativeBoost/ > merci > > sous Windows, je vais plus loin que prÃ©cÃ©demment, mais au lancement > d'un exemple Athens je reÃ§ois ce message: > Error: define your own path > > sous mac j'ai une erreur au lancement de la machine virtuelle (NB-Cog-Mac-Cocoa) > mais comme je le disais dans un mail prÃ©cÃ©dent, je suis sous OSX > 10.5.8 (il va falloir que je finisse par faire la mise Ã jour ;) > Voici le rapport de crash: > > Date/Time: 2012-04-24 13:54:41.233 +0200 > OS Version: Mac OS X 10.5.8 (9L30) > Report Version: 6 > Anonymous UUID: FC86FDF9-C4F0-456D-ACF2-2771397F846A > > Exception Type: EXC_BREAKPOINT (SIGTRAP) > Exception Codes: 0x0000000000000002, 0x0000000000000000 > Crashed Thread: 0 > > Dyld Error Message: > unknown required load command 0x80000022 > > > th

April 24, 2012

Re: [Pharo-project] new icon set

by Norbert Hartl

Am 24.04.2012 um 14:37 schrieb Igor Stasenko: > On 24 April 2012 14:13, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Am 24.04.2012 um 14:06 schrieb Esteban Lorenzano: >> >>> but, Norbert, I don't see the point. In a server you will not have (or *should* not have) a display... so rendering time, etc. is non an issue, because it will not be any... or I'm missing something? >>> >> I think most people using pharo on the server are using VNC to maintain them. I do that,too, in lack of a better tool. So in this case there is a display and there are icons. Rendering is not an issue as long as you suspend to UI thread until you need it. >> So, let me just repeat >> >> ...new icons.... cool! >> ...svg icons.....cool! >> ...removable icons...cool! >> >> That's basically all I wanted to say. >> > > and this is not preventing an operating systems from having even more > rich graphics and still use remote desktop connections? > i don't share your concerns.. because we're talking about different > terms of use. > for desktop applications we need a modern rich graphics and eye candy. > this not a question. > > for servers you can live perfectly with command-line tools only, and > pharoers also working in that direction.. > so it is not an exclusive choice where you should pick between one > over another. > you can have both: minimal memory footprint on server(s) and decent > graphics on desktop. i am talking about modular system, where you can > (un)load modules at your please, and we're moving towards it. Igor, I didn't say there should be one approach and that you need to choose. I tried to make explicit that having options is a good thing. And that includes the joy of using a commandline for a server or not. You have no reason to decide for everyone that they should live with commandline tools on the server. I was talking about the near future and you reach far more off. Of course I like to have a tiny pharo image running on a server that lets me connect from my development image and lets me debug/inspect everything from remote where everything is either SVG or opengl. But I don't expect that to happen tomorrow or the day after. There is a need for short term solution. Or to make fun of a quote Don't obscure my reality with your future Norbert

April 24, 2012

Re: [Pharo-project] new icon set

by Igor Stasenko

On 24 April 2012 14:13, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 24.04.2012 um 14:06 schrieb Esteban Lorenzano: > >> but, Norbert, I don't see the point. In a server you will not have (or *should* not have) a display... so rendering time, etc. is non an issue, because it will not be any... or I'm missing something? >> > I think most people using pharo on the server are using VNC to maintain them. I do that,too, Â in lack of a better tool. So in this case there is a display and there are icons. Rendering is not an issue as long as you suspend to UI thread until you need it. > So, let me just repeat > > ...new icons.... cool! > ...svg icons.....cool! > ...removable icons...cool! > > That's basically all I wanted to say. > and this is not preventing an operating systems from having even more rich graphics and still use remote desktop connections? i don't share your concerns.. because we're talking about different terms of use. for desktop applications we need a modern rich graphics and eye candy. this not a question. for servers you can live perfectly with command-line tools only, and pharoers also working in that direction.. so it is not an exclusive choice where you should pick between one over another. you can have both: minimal memory footprint on server(s) and decent graphics on desktop. i am talking about modular system, where you can (un)load modules at your please, and we're moving towards it. > Norbert > -- Best regards, Igor Stasenko.

April 24, 2012

Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]

by H. Hirzel

Igor, Let me rephrase the context. It is that you started this thread yesterday Monday Apr 23, 2012 at 11:34 .You said that you are not pleased with storing Smalltalk meta data in JSON format. You gave the example { "category" : "Cypress-Tests", "classinstvars" : [ ], "classtraitcomposition" : "{}", "classvars" : [ ], "commentStamp" : "", "instvars" : [ ], "name" : "CypressPatchTest", "pools" : [ ], "super" : "CypressAbstractTest", "traitcomposition" : "{}", "type" : "normal" } The cypress project URL is https://github.com/CampSmalltalk/Cypress This is Dale Henrichs' work. Cypress uses JSON for storing the meta data. There is a button called 'Fork' on the git hub project. Dale is willing to take arguments if they are based on code. For many people JSON is fine. HTH :-) Hannes On 4/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 April 2012 14:17, Herby VojÄÃk <herby(a)mailbox.sk> wrote: >> >> >> Igor Stasenko wrote: >>> >>> On 24 April 2012 11:54, Dale Henrichs<dhenrich(a)vmware.com> Â wrote: >>>> >>>> Stef, >>>> >>>> There is no Parser class and there is no Compiler class. There is a >>>> primitive call that takes method source, class, methodDictionary, etc. >>>> and >>>> produces a method installed in the methodDictionary. >>>> >>> so you can take 1st literal from such method and you done. or you >>> cannot access method's literals? >>> it of course not as simple as parsing the source, but if you cannot >>> avoid compilation.. >>> >>>> ... JSON is and was a pragmatic choice... >>>> >>> well, i did not realized that GemStone have no own parser/compiler >>> written in smalltalk. >> >> >> Neither does Amber in deploy mode, unless I am mistaken. >> >> Why do you ever think there must be a Smalltalk parser in any Smalltalk? >> You >> get used to it, I understand, but it is by no means a required thing. >> Smalltalk is Smalltalk without parser as well. >> >> JSON is great choice. Much better than anything proprietary, because of >> world-wide interoperability. >> > > Sorry, but you seem even more out of the context than me. > We're talking about tools for storing and loading smalltalk code.. > which implies having a working smalltalk > parser and compiler toolchain. > How else you can load smalltalk source code without having the way to parse > it? > If you don't parse nor compile it, it is just a bunch of letters. > >> Herby >> > > > > -- > Best regards, > Igor Stasenko. > >

April 24, 2012

Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]

by Igor Stasenko

yeah, lets put another canister of fuel into the flame: hey, who needs that odd smalltalk syntax? who says that smalltalk source code should have original syntax? lets express it in JSON!! On 24 April 2012 14:22, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 April 2012 14:17, Herby VojÄÃk <herby(a)mailbox.sk> wrote: >> >> >> Igor Stasenko wrote: >>> >>> On 24 April 2012 11:54, Dale Henrichs<dhenrich(a)vmware.com> Â wrote: >>>> >>>> Stef, >>>> >>>> There is no Parser class and there is no Compiler class. There is a >>>> primitive call that takes method source, class, methodDictionary, etc. and >>>> produces a method installed in the methodDictionary. >>>> >>> so you can take 1st literal from such method and you done. or you >>> cannot access method's literals? >>> it of course not as simple as parsing the source, but if you cannot >>> avoid compilation.. >>> >>>> ... JSON is and was a pragmatic choice... >>>> >>> well, i did not realized that GemStone have no own parser/compiler >>> written in smalltalk. >> >> >> Neither does Amber in deploy mode, unless I am mistaken. >> >> Why do you ever think there must be a Smalltalk parser in any Smalltalk? You >> get used to it, I understand, but it is by no means a required thing. >> Smalltalk is Smalltalk without parser as well. >> >> JSON is great choice. Much better than anything proprietary, because of >> world-wide interoperability. >> > > Sorry, but you seem even more out of the context than me. > We're talking about tools for storing and loading smalltalk code.. > which implies having a working smalltalk > parser and compiler toolchain. > How else you can load smalltalk source code without having the way to parse it? > If you don't parse nor compile it, it is just a bunch of letters. > >> Herby >> > > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

April 24, 2012

Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]

by Igor Stasenko

On 24 April 2012 14:17, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > > > Igor Stasenko wrote: >> >> On 24 April 2012 11:54, Dale Henrichs<dhenrich(a)vmware.com> Â wrote: >>> >>> Stef, >>> >>> There is no Parser class and there is no Compiler class. There is a >>> primitive call that takes method source, class, methodDictionary, etc. and >>> produces a method installed in the methodDictionary. >>> >> so you can take 1st literal from such method and you done. or you >> cannot access method's literals? >> it of course not as simple as parsing the source, but if you cannot >> avoid compilation.. >> >>> ... JSON is and was a pragmatic choice... >>> >> well, i did not realized that GemStone have no own parser/compiler >> written in smalltalk. > > > Neither does Amber in deploy mode, unless I am mistaken. > > Why do you ever think there must be a Smalltalk parser in any Smalltalk? You > get used to it, I understand, but it is by no means a required thing. > Smalltalk is Smalltalk without parser as well. > > JSON is great choice. Much better than anything proprietary, because of > world-wide interoperability. > Sorry, but you seem even more out of the context than me. We're talking about tools for storing and loading smalltalk code.. which implies having a working smalltalk parser and compiler toolchain. How else you can load smalltalk source code without having the way to parse it? If you don't parse nor compile it, it is just a bunch of letters. > Herby > -- Best regards, Igor Stasenko.

April 24, 2012

Re: [Pharo-project] new icon set

by Esteban Lorenzano

you have 1 and 3 :) for svg, we still need to wait a bit :) On Apr 24, 2012, at 2:13 PM, Norbert Hartl wrote: > > Am 24.04.2012 um 14:06 schrieb Esteban Lorenzano: > >> but, Norbert, I don't see the point. In a server you will not have (or *should* not have) a display... so rendering time, etc. is non an issue, because it will not be any... or I'm missing something? >> > I think most people using pharo on the server are using VNC to maintain them. I do that,too, in lack of a better tool. So in this case there is a display and there are icons. Rendering is not an issue as long as you suspend to UI thread until you need it. > So, let me just repeat > > ...new icons.... cool! > ...svg icons.....cool! > ...removable icons...cool! > > That's basically all I wanted to say. > > Norbert > >> cheers, >> Esteban >> >> On Apr 24, 2012, at 2:02 PM, Norbert Hartl wrote: >> >>> >>> Am 24.04.2012 um 12:50 schrieb Igor Stasenko: >>> >>>> On 24 April 2012 11:44, Norbert Hartl <norbert(a)hartl.name> wrote: >>>>> >>>>> Am 24.04.2012 um 11:35 schrieb Geert Claes: >>>>> >>>>>> >>>>>> Norbert Hartl wrote >>>>>>> >>>>>>> Of course, if there is an ugly replacment that can be used if the system >>>>>>> is minimised. Having two icon sets introduces the possibility to make the >>>>>>> ugly one consume even less memory, e.g. make it black and white. >>>>>>> >>>>>> >>>>>> I have no idea what you just tried to say :) When you say ugly replacement, >>>>>> are you talking about the current ugly icons or do you find Esteban's >>>>>> suggested icons not appealing enough? >>>>>> >>>>> It is just an addition to my first statement. If we call the current icon set medium in the sense of medium cutiness and medium memory consumption than there is a new situation with the new nice icons. Igor is right, if the vector world is coming to pharo then it is easy to make really good looking icons in the image. But the memory consumption and CPU intensity will be raised. That contradicts to usage of pharo in a server environment. So what I was saying is that I think that the new icons are great. But then there should be a replacement for it when the image is shrinked. The same happens with the fonts if you shrink. And if the icons are replaced they could even be replaced by something really basic that saves additional memory. On a server with VNC or the like the icons aren't that important and maybe can be removed completely. >>>>> >>>>> More clear now? >>>>> >>>>> Norbert >>>>> >>>>> >>>> >>>> did i miss something? since when memory consumption for vector >>>> graphics takes more space? >>>> look at the size of .svg files and compare them with size of .png >>>> files for same icons. >>> >>> There is a difference between storage size and in-memory size. The storage size is important if you put the resource class-based. For the rest you need to decide. Either you render the icon every update from source or you do cache and from then on you have storage size + in-memory size for your icons. If you do fancy stuff automatically which means it probably uses a lot of colors so this can be quite big. >>> >>>> Vector data are much more compact. >>>> So, actually if you really want to shrink things down, you need to >>>> operate with vectors :) >>> >>> Yes, and then you need a lot of cpu cycles. Just what I said. >>> >>>> More CPU for rendering vector graphics? Perhaps. >>>> It is of course more expensive than just copying memory from one >>>> bitmap to another. >>>> But desktop environment requires a lot more complex operations that >>>> just copying bits from one form over >>>> another one. >>>> And also consider the cases where you need to use 5 different >>>> operations to simulate just one. >>>> (look at famous corner rounder hack). >>> >>> Again what I said. It is feasible to have good looking stuff. But everything you said is unimportant on a server. I'm just begging you not to forget that. That's all. Nothing against any of your plans. It will make pharo better. >>> >>> Norbert >> >> > >

April 24, 2012

Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]

by Herby VojÄÃk

Igor Stasenko wrote: > On 24 April 2012 11:54, Dale Henrichs<dhenrich(a)vmware.com> wrote: >> Stef, >> >> There is no Parser class and there is no Compiler class. There is a primitive call that takes method source, class, methodDictionary, etc. and produces a method installed in the methodDictionary. >> > so you can take 1st literal from such method and you done. or you > cannot access method's literals? > it of course not as simple as parsing the source, but if you cannot > avoid compilation.. > >> ... JSON is and was a pragmatic choice... >> > well, i did not realized that GemStone have no own parser/compiler > written in smalltalk. Neither does Amber in deploy mode, unless I am mistaken. Why do you ever think there must be a Smalltalk parser in any Smalltalk? You get used to it, I understand, but it is by no means a required thing. Smalltalk is Smalltalk without parser as well. JSON is great choice. Much better than anything proprietary, because of world-wide interoperability. Herby

April 24, 2012

Re: [Pharo-project] new icon set

by Norbert Hartl

Am 24.04.2012 um 14:06 schrieb Esteban Lorenzano: > but, Norbert, I don't see the point. In a server you will not have (or *should* not have) a display... so rendering time, etc. is non an issue, because it will not be any... or I'm missing something? > I think most people using pharo on the server are using VNC to maintain them. I do that,too, in lack of a better tool. So in this case there is a display and there are icons. Rendering is not an issue as long as you suspend to UI thread until you need it. So, let me just repeat ...new icons.... cool! ...svg icons.....cool! ...removable icons...cool! That's basically all I wanted to say. Norbert > cheers, > Esteban > > On Apr 24, 2012, at 2:02 PM, Norbert Hartl wrote: > >> >> Am 24.04.2012 um 12:50 schrieb Igor Stasenko: >> >>> On 24 April 2012 11:44, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> Am 24.04.2012 um 11:35 schrieb Geert Claes: >>>> >>>>> >>>>> Norbert Hartl wrote >>>>>> >>>>>> Of course, if there is an ugly replacment that can be used if the system >>>>>> is minimised. Having two icon sets introduces the possibility to make the >>>>>> ugly one consume even less memory, e.g. make it black and white. >>>>>> >>>>> >>>>> I have no idea what you just tried to say :) When you say ugly replacement, >>>>> are you talking about the current ugly icons or do you find Esteban's >>>>> suggested icons not appealing enough? >>>>> >>>> It is just an addition to my first statement. If we call the current icon set medium in the sense of medium cutiness and medium memory consumption than there is a new situation with the new nice icons. Igor is right, if the vector world is coming to pharo then it is easy to make really good looking icons in the image. But the memory consumption and CPU intensity will be raised. That contradicts to usage of pharo in a server environment. So what I was saying is that I think that the new icons are great. But then there should be a replacement for it when the image is shrinked. The same happens with the fonts if you shrink. And if the icons are replaced they could even be replaced by something really basic that saves additional memory. On a server with VNC or the like the icons aren't that important and maybe can be removed completely. >>>> >>>> More clear now? >>>> >>>> Norbert >>>> >>>> >>> >>> did i miss something? since when memory consumption for vector >>> graphics takes more space? >>> look at the size of .svg files and compare them with size of .png >>> files for same icons. >> >> There is a difference between storage size and in-memory size. The storage size is important if you put the resource class-based. For the rest you need to decide. Either you render the icon every update from source or you do cache and from then on you have storage size + in-memory size for your icons. If you do fancy stuff automatically which means it probably uses a lot of colors so this can be quite big. >> >>> Vector data are much more compact. >>> So, actually if you really want to shrink things down, you need to >>> operate with vectors :) >> >> Yes, and then you need a lot of cpu cycles. Just what I said. >> >>> More CPU for rendering vector graphics? Perhaps. >>> It is of course more expensive than just copying memory from one >>> bitmap to another. >>> But desktop environment requires a lot more complex operations that >>> just copying bits from one form over >>> another one. >>> And also consider the cases where you need to use 5 different >>> operations to simulate just one. >>> (look at famous corner rounder hack). >> >> Again what I said. It is feasible to have good looking stuff. But everything you said is unimportant on a server. I'm just begging you not to forget that. That's all. Nothing against any of your plans. It will make pharo better. >> >> Norbert > >

April 24, 2012