- Pharo-dev - lists.pharo.org

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

[Pharo-project] GSoC news: we have 13 projects!

by Janko MivÅ¡ek

Dear Smalltalkers! We have 13 GSoC projects and let we welcome to all students whose proposals were accepted: 1. Santiago Bragagnolo Concrete Type Inference -- Call graph http://gsoc2012.esug.org/projects/type-inference 2. Lars Wassermann ARM jitter for Squeak VM http://gsoc2012.esug.org/projects/arm-jitter 3. Facundo Mainere Interactive & social online Smalltalk tutorial http://gsoc2012.esug.org/projects/interactive-tutorial 4. Benjamin Van Ryseghem Nautilus http://gsoc2012.esug.org/projects/nautilus 5. MartÃn Dias Package management with Fuel http://gsoc2012.esug.org/projects/fuel-packages 6. Guillermo Polito Bootstrapping the core-Hazelnut http://gsoc2012.esug.org/projects/hazelnut 7. Pablo Estefo TestSurgeon http://gsoc2012.esug.org/projects/testsurgeon 8. Daniel Uber SciSmalltalk http://gsoc2012.esug.org/projects/sci-smalltalk 9. Rustem Khubbatov HMI (Human-Machine Interface) with Amber http://gsoc2012.esug.org/projects/mmi-amber 10. Juan Pablo Sandoval Alcocer Rizel - Multidimensional Profiler http://gsoc2012.esug.org/projects/rizel 11. Saurav Bhattacharya Export Excel files and other spreadsheet related goodies http://gsoc2012.esug.org/projects/excel-export 12. Steve Granda Finish Physical Etoys port to Sugar http://gsoc2012.esug.org/projects/etoys-sugar 13. Paul Kuzovkin Esse, a framework for visualizing, storing and exploring ideas http://gsoc2012.esug.org/projects/esse 5 students from Argentina, 2 from Chile, 2 from Russia, 1 from Sweden, France, USA and let we specially welcome our first Indian student! Now a Community bonding period started, when students get to know mentors, read documentation, get up to speed to begin working on their projects. Until 21.May when coding begin. Good luck to everyone! Janko @ Carla -- Smalltalk GSoC Admin Team http://gsoc2012.esug.org

April 24, 2012

Re: [Pharo-project] Pharo and the rest of the ecosystem

by Fernando Olivero

That's a good point. I regularly see that Stef and others harvest enhancements and fixes from Squeak and CUIS. Surely, the other way around is also true. We simply have to live with the fact that many forks exist, and each of them is maintained by a small set of people who put a lot of energy into their own system. And sometimes they will collaborate, and sometimes not. The community behind Pharo, shouldnt be required to always be aware of external enhancements. And vice-versa for the remaining forks. Fernando On Tue, Apr 24, 2012 at 12:38 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Now I do not see the points related to spoon and cuis. I do not understand what is the point. >>> If people wants to collaborate with us this is ok now we do not count on that for our future. >>> >>> You do not have to reply. Just think about what you want to build and your future. Everybody >>> make choices and is free. >> >> I see the point behind Cuis/Spoon discussion in a wish to avoid >> duplication efforts in Smalltalk community. A wish to hear from you a >> word, something like: "yes we will look in Cuis to see if we can reuse >> some ideas or even code". To express just a will to look at achievements >> of others would help here. I think this is what many of us wants to hear. > > Did you notice that we ***already*** harvested some of the CUIS items? > Now it does not make sense to stay compatible for the sake of it. > Look CUIS changes the class definition meta data and this is ok. Now nobody went to say > to Juan that he should not â¦ blablbalbalba > > Stef > >> Best regards >> Janko >> >> >> >> -- >> Janko MivÅ¡ek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> > >

April 24, 2012

Re: [Pharo-project] new icon set

by 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? 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] new icon set

by Norbert Hartl

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