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

Re: [Pharo-project] Pharo Core 1.3 - Build # 19 - Unstable!

by Marcus Denker

On Mar 8, 2012, at 7:26 PM, Sven Van Caekenberghe wrote: > > All Zn tests pass, on my machine/VM, as they do/did at http://jenkins.lukas-renggli.ch/job/Zinc/ > I think they are alll failing because a test server could not be started properly, most probably because the port is already in use. > Could these tests be running more than once on the same machine ? Yes, that can happen. We should try to avoid it. The Zinc test are run by -> 1.4 unix tests -> all cog unix vm regression tests -> 1.3 Full Maybe we need to go to 1 Jenkins executor per machine? > Will this test run/build be attempted again automatically ? > Yes, latest when I add the next update for 1.3... -- Marcus Denker -- http://marcusdenker.de

March 9, 2012

Re: [Pharo-project] Adding a statement programmatically

by Norbert Hartl

Am 08.03.2012 um 20:05 schrieb "Sean P. DeNigris" <sean(a)clipperadams.com>: > > Norbert Hartl wrote >> >> Try... > > Thanks Norbert. Same result. > Does not work? What do you mean by saying "same result"? Norbert > -- > View this message in context: http://forum.world.st/Adding-a-statement-programmatically-tp4454447p4457352… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 9, 2012

Re: [Pharo-project] EPUB view for Pier Books

by Nick Ager

Hi Yanni, On 8 March 2012 16:51, Yanni Chiu <yanni(a)rogers.com> wrote: > On 08/03/12 2:58 AM, Nick Ager wrote: > >> Have you had any luck viewing the output ePUB file with iBooks on iOS? I >> tried with my iPhone but it wouldn't open. I also noticed that the >> section link wasn't numbered - any thoughts? >> > > I don't have iBooks, iOS, iPhone to try, but I'll try the dev simulator on > MacOSX. > > I'm not sure what is meant by section link number. The EPUB standard > appeared to be a maze of other standards and some now deprecated specs. So > rather than decipher the spec, I unzipped a few example EPUB books, and > gleaned a small subset to implement. > > Here's my plan: > > 1. Add my test Pier book as a TestCase > 2. Add a way to include a .css stylesheet > 3. Fix bugs reported on different platforms This sounds great - look forward to hearing how you get along Nick

March 9, 2012

Re: [Pharo-project] ClassBuilder depending -in some way- on text

by Chris Cunningham

On Thu, Mar 8, 2012 at 5:17 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 9 March 2012 01:22, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> ClassBuilder>>validateClassName: aString ... >> Â Â Â Â Â Â Â Â Â self notify: aString asText allBold, >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ' already exists!\Proceed will store over it.' >> >> Is it right to do that asText allBold there? :S >> Shouldn't an exception be raised instead? >> >> Do I open a ticket? >> > Yes. > We should kill dependency by removing asText asBold. > Notifications should not accept rich-formatted text anyways, > because not all ui managers can handle it Â (now we having command-line > ui manager > which prints message on console). > Maybe have the command-line ui manager dumb down the representation - I'm sure this isn't the only place. Guille, this likely pre-dates Exceptions (or at least wide-spread use of them). A much better direction is to use exceptions (or Announcements?) here, and have a process capture them and display appropriately for what they can display. The mechanism should probably include Class name and exception text, which could be rich-formatted as above, or plain formatted for command-line UI, or interrogated for other observers. Just suggestions. -Chris

March 9, 2012

Re: [Pharo-project] ClassBuilder depending -in some way- on text

by Igor Stasenko

On 9 March 2012 01:22, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > ClassBuilder>>validateClassName: aString > Â Â Â "Validate the new class name" > Â Â Â | allowed | > Â Â Â aString isSymbol > Â Â Â Â Â Â ifFalse: [ ^ false ]. > Â Â Â allowed := ($0 to: $9), {$_}, ($A to: $Z), ($a to: $z). > Â Â Â (aString detect: [:c | (allowed includes: c) not] ifNone: [ ]) > Â Â Â Â Â Â ifNotNil: [ :c | self error: 'Invalid character: ''', c printString, > ''''. > Â Â Â Â Â Â Â Â Â ^ false]. > Â Â Â aString first canBeGlobalVarInitial ifFalse:[ > Â Â Â Â Â Â self error: 'Class names must be capitalized'. > Â Â Â Â Â Â ^false]. > Â Â Â environ at: aString ifPresent:[:old| > Â Â Â Â Â Â (old isKindOf: Behavior) ifFalse:[ > Â Â Â Â Â Â Â Â Â self notify: aString asText allBold, > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ' already exists!\Proceed will store over it.' > withCRs]]. > Â Â Â ^ true > > > Is it right to do that asText allBold there? :S > Shouldn't an exception be raised instead? > > Do I open a ticket? > Yes. We should kill dependency by removing asText asBold. Notifications should not accept rich-formatted text anyways, because not all ui managers can handle it (now we having command-line ui manager which prints message on console). > Guille -- Best regards, Igor Stasenko.

March 9, 2012

Re: [Pharo-project] more Nautilus feed back

by Igor Stasenko

just want to correct myself. I used Nautilus before.. but it is not my "all day" tool, because there are myriads of images i had to work in, and most of them don't have nautilus. That's why i don't feel myself in a position to give feedback at this point. On 9 March 2012 00:50, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > On Mar 9, 2012, at 12:17 AM, Igor Stasenko wrote: > >> On 8 March 2012 23:24, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>> >>> On Mar 8, 2012, at 8:25 PM, Esteban Lorenzano wrote: >>> >>> Hi, >>> >>> I'm using Nautilus for my current projects since... well... couple of days, >>> and I have some Â feedback: >>> >>> (yeah... maybe they are dumb reports, but that's because you did a great >>> work with nautilus, I just have some really small observations :) >>> >>> 1) OB had double-click action: show hierarchy. I miss it a lot :( >>> >>> >>> If you activate the "open a class on hierarchy" setting, it does the same :) >>> >>> Also, hierarchy button is too far away when I want to see the >>> hierarchy... ok, if you don't want to add double click functionality... can >>> it be a menu option? (show hierarchy (h)) >>> >>> >>> Maybe I should switch the group button and the hierarchy button. It will >>> make more sense :) >>> >>> Even worst: it swaps panels which is very confusing... but that leads to >>> point 2 :) >>> >>> >>> There are some good arguments to do that :) But I am quite fed up to tell >>> them again and again ^^ >>> >>> 2) swap panel configuration is not working for me in latest pharo 1.4 >>> >>> >>> Ie ? >>> >>> 3) I find "Class", "Instance" buttons very confusing. I liked more the older >>> solution but well, I understand you want to improve visibility of comments, >>> but then, I think class button would be better as a "toggle" button (those >>> buttons who stays pressed) >>> >>> >>> Do you have an example of such a button ? >>> >>> 4) bold for class side method and categories is too strong, I don't see any >>> reason for that, we have panel titles and future ;) toggle button to know >>> which side is. >>> >>> >>> Some people (Laurent not toell who) complain about the lack of visibility. >>> And indeed, I found than when you have multiples browsers, it helps a lot to >>> find where you are in a second. >>> >>> 5) OB had a #browserIcon method on classes who changed class icon on >>> browser. This is really useful for knowing different types/hierarchies like >>> errors, announcements, morphs, etc. Again, this collides with "uncommented" >>> icon, but I would like to have them back... >>> >>> >>> There are icons for >>> Morph/Erros/Announcements/Magnitude/String/Collection/etc... But maybe I >>> could also add a mechanism to let each class defines it's own icon. >>> >>> 6) I'm sorry for saying this, but I don't like the icons, nor the colored >>> options (source, bytecode, decompiled, etc.) at the side. I would prefer a >>> combo on button panel... and better looking icons (yes Stef, FamFam icons is >>> ok :) >>> >>> >>> I will be really glad to use yours :) You know, I am kind of a programmer. >>> It means that making icons is not my work. And due to that, it takes me ages >>> to do them. >>> I have no problem to change them at all, but I really don't have time to do >>> them. >>> >> so then go finish arts and design schools (min 5 years each). and only >> then you may get back and continue working on nautilus! Hurry up. :) > > I will think about that :) > >>> 7) Why we have a button panel (which is in fact a toolbar) in the middle of >>> the browser and not where it belongs: on top? this is a remain of OB, who >>> took this from old Browser... but conceptually (as in usability terms), this >>> is a not-good solution. We could think on change this and place the button >>> bar where it belongs (and add some cool keybindings too) >>> >>> >>> You can't say that the hierarchy button is to far, and ask for putting the >>> toolbar on top ^^ >>> It's here because it's close to the lists (where you spend 20% of your time) >>> and also close to the source code (where you spend 80% of your time). >>> >>> 8) different sized buttons are a really bad concept. Yes... in Smalltalk >>> this is very common: to create buttons with the size of text... but this is >>> bad design because disrupts harmony, and that hurts to the eyes... and when >>> something hurts, you try not to use it :) >>> >>> >>> I can't agree more. But buttons are kind of a pain in the ass (because they >>> are embedded into a group morph with its own layout etc). As soon as I can >>> set >>> vResizing: #rigid; hResizing: #rigid, I'll do it for sure ^^ >>> >>> >>> yeah.. most of my observations are also for any other tool we have, and most >>> are about usability... I humbly recommend (for all people doing GUIs), the >>> lecture of this book: http://en.wikipedia.org/wiki/Don't_Make_Me_Think. It >>> is for web design, but is also a great guide when you want to make things >>> people like. >>> >>> (Also, reading apple design guide is a good way to notice some interesting >>> things... those guys had invest an insanely amount of time and money in >>> development them) >>> >>> >>> I will try to find time to read them, but as I said, my exams are in 11 days >>> so ;) >>> >> no. arts school first. > > I just finished my registration ;) > >> >> ohh.. nothing is perfect. changes are not always better to what we had. >> but staying is worst of everything. >> just keep pushing. >> >> I can also easily tell what i don't like in Nautilus. Much harder is >> to propose alternative. >> I think that feedback about UI should always come with alternative, >> explaining why you think its better. Or if one feels that old ways is >> better he should argument that (an argument 'because i get used to it' >> is WRONG argument ;). >> >> Today i had full day hacking using Nautilus. And found some bugs. Hope >> next iteration they will be fixed. :) >> There are some rough corners here and there, but overall impression - >> it is quite good. >> I will be starting giving more feedback once i will get used to it. >> Because 1 day is too little to say anything definitive.. i need more >> immersion to make my feedback more problem-oriented, not tainted by "i >> don't like it because it different" attitude. > > I am waiting for your feedback so :) > >> >>> >>> Thanks for the feedback :) >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

March 9, 2012

[Pharo-project] ClassBuilder depending -in some way- on text

by Guillermo Polito

ClassBuilder>>validateClassName: aString "Validate the new class name" | allowed | aString isSymbol ifFalse: [ ^ false ]. allowed := ($0 to: $9), {$_}, ($A to: $Z), ($a to: $z). (aString detect: [:c | (allowed includes: c) not] ifNone: [ ]) ifNotNil: [ :c | self error: 'Invalid character: ''', c printString, ''''. ^ false]. aString first canBeGlobalVarInitial ifFalse:[ self error: 'Class names must be capitalized'. ^false]. environ at: aString ifPresent:[:old| (old isKindOf: Behavior) ifFalse:[ *self notify: aString asText allBold, * ' already exists!\Proceed will store over it.' withCRs]]. ^ true Is it right to do that asText allBold there? :S Shouldn't an exception be raised instead? Do I open a ticket? Guille

March 9, 2012

Re: [Pharo-project] more Nautilus feed back

by Benjamin

On Mar 9, 2012, at 12:17 AM, Igor Stasenko wrote: > On 8 March 2012 23:24, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> >> On Mar 8, 2012, at 8:25 PM, Esteban Lorenzano wrote: >> >> Hi, >> >> I'm using Nautilus for my current projects since... well... couple of days, >> and I have some feedback: >> >> (yeah... maybe they are dumb reports, but that's because you did a great >> work with nautilus, I just have some really small observations :) >> >> 1) OB had double-click action: show hierarchy. I miss it a lot :( >> >> >> If you activate the "open a class on hierarchy" setting, it does the same :) >> >> Also, hierarchy button is too far away when I want to see the >> hierarchy... ok, if you don't want to add double click functionality... can >> it be a menu option? (show hierarchy (h)) >> >> >> Maybe I should switch the group button and the hierarchy button. It will >> make more sense :) >> >> Even worst: it swaps panels which is very confusing... but that leads to >> point 2 :) >> >> >> There are some good arguments to do that :) But I am quite fed up to tell >> them again and again ^^ >> >> 2) swap panel configuration is not working for me in latest pharo 1.4 >> >> >> Ie ? >> >> 3) I find "Class", "Instance" buttons very confusing. I liked more the older >> solution but well, I understand you want to improve visibility of comments, >> but then, I think class button would be better as a "toggle" button (those >> buttons who stays pressed) >> >> >> Do you have an example of such a button ? >> >> 4) bold for class side method and categories is too strong, I don't see any >> reason for that, we have panel titles and future ;) toggle button to know >> which side is. >> >> >> Some people (Laurent not toell who) complain about the lack of visibility. >> And indeed, I found than when you have multiples browsers, it helps a lot to >> find where you are in a second. >> >> 5) OB had a #browserIcon method on classes who changed class icon on >> browser. This is really useful for knowing different types/hierarchies like >> errors, announcements, morphs, etc. Again, this collides with "uncommented" >> icon, but I would like to have them back... >> >> >> There are icons for >> Morph/Erros/Announcements/Magnitude/String/Collection/etc... But maybe I >> could also add a mechanism to let each class defines it's own icon. >> >> 6) I'm sorry for saying this, but I don't like the icons, nor the colored >> options (source, bytecode, decompiled, etc.) at the side. I would prefer a >> combo on button panel... and better looking icons (yes Stef, FamFam icons is >> ok :) >> >> >> I will be really glad to use yours :) You know, I am kind of a programmer. >> It means that making icons is not my work. And due to that, it takes me ages >> to do them. >> I have no problem to change them at all, but I really don't have time to do >> them. >> > so then go finish arts and design schools (min 5 years each). and only > then you may get back and continue working on nautilus! Hurry up. :) I will think about that :) >> 7) Why we have a button panel (which is in fact a toolbar) in the middle of >> the browser and not where it belongs: on top? this is a remain of OB, who >> took this from old Browser... but conceptually (as in usability terms), this >> is a not-good solution. We could think on change this and place the button >> bar where it belongs (and add some cool keybindings too) >> >> >> You can't say that the hierarchy button is to far, and ask for putting the >> toolbar on top ^^ >> It's here because it's close to the lists (where you spend 20% of your time) >> and also close to the source code (where you spend 80% of your time). >> >> 8) different sized buttons are a really bad concept. Yes... in Smalltalk >> this is very common: to create buttons with the size of text... but this is >> bad design because disrupts harmony, and that hurts to the eyes... and when >> something hurts, you try not to use it :) >> >> >> I can't agree more. But buttons are kind of a pain in the ass (because they >> are embedded into a group morph with its own layout etc). As soon as I can >> set >> vResizing: #rigid; hResizing: #rigid, I'll do it for sure ^^ >> >> >> yeah.. most of my observations are also for any other tool we have, and most >> are about usability... I humbly recommend (for all people doing GUIs), the >> lecture of this book: http://en.wikipedia.org/wiki/Don't_Make_Me_Think. It >> is for web design, but is also a great guide when you want to make things >> people like. >> >> (Also, reading apple design guide is a good way to notice some interesting >> things... those guys had invest an insanely amount of time and money in >> development them) >> >> >> I will try to find time to read them, but as I said, my exams are in 11 days >> so ;) >> > no. arts school first. I just finished my registration ;) > > ohh.. nothing is perfect. changes are not always better to what we had. > but staying is worst of everything. > just keep pushing. > > I can also easily tell what i don't like in Nautilus. Much harder is > to propose alternative. > I think that feedback about UI should always come with alternative, > explaining why you think its better. Or if one feels that old ways is > better he should argument that (an argument 'because i get used to it' > is WRONG argument ;). > > Today i had full day hacking using Nautilus. And found some bugs. Hope > next iteration they will be fixed. :) > There are some rough corners here and there, but overall impression - > it is quite good. > I will be starting giving more feedback once i will get used to it. > Because 1 day is too little to say anything definitive.. i need more > immersion to make my feedback more problem-oriented, not tainted by "i > don't like it because it different" attitude. I am waiting for your feedback so :) > >> >> Thanks for the feedback :) >> > > > -- > Best regards, > Igor Stasenko. >

March 8, 2012

Re: [Pharo-project] GSoC: ARM jitter for Squeak VM

by Alexis Parseghian

In case you'd rather work on real hardware instead of an emulator, I can recommend Genesi machines (I am not affiliated with them) : http://www.genesi-usa.com/products It's well-designed, inexpensive and supports both armel and armhf ABIs (one of the guys behind the debian armhf port works mostly on a Smartbook). Besides, they take customer support very seriously.

March 8, 2012

Re: [Pharo-project] more Nautilus feed back

by Igor Stasenko

On 8 March 2012 23:24, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > On Mar 8, 2012, at 8:25 PM, Esteban Lorenzano wrote: > > Hi, > > I'm using Nautilus for my current projects since... well... couple of days, > and I have some Â feedback: > > (yeah... maybe they are dumb reports, but that's because you did a great > work with nautilus, I just have some really small observations :) > > 1) OB had double-click action: show hierarchy. I miss it a lot :( > > > If you activate the "open a class on hierarchy" setting, it does the same :) > > Also, hierarchy button is too far away when I want to see the > hierarchy...Â ok, if you don't want to add double click functionality... can > it be a menu option? (show hierarchy (h)) > > > Maybe I should switch the group button and the hierarchy button. It will > make more sense :) > > Even worst: it swaps panels which is very confusing... but that leads to > point 2 :) > > > There are some good arguments to do that :) But I am quite fed up to tell > them again and again ^^ > > 2) swap panel configuration is not working for me in latest pharo 1.4 > > > Ie ? > > 3) I find "Class", "Instance" buttons very confusing. I liked more the older > solution but well, I understand you want to improve visibility of comments, > but then, I think class button would be better as a "toggle" button (those > buttons who stays pressed) > > > Do you have an example of such a button ? > > 4) bold for class side method and categories is too strong, I don't see any > reason for that, we have panel titles and future ;) toggle button to know > which side is. > > > Some people (Laurent not toell who) complain about the lack of visibility. > And indeed, I found than when you have multiples browsers, it helps a lot to > find where you are in a second. > > 5) OB had a #browserIcon method on classes who changed class icon on > browser. This is really useful for knowing different types/hierarchies like > errors, announcements, morphs, etc. Again, this collides with "uncommented" > icon, but I would like to have them back... > > > There are icons for > Morph/Erros/Announcements/Magnitude/String/Collection/etc... But maybe I > could also add a mechanism to let each class defines it's own icon. > > 6) I'm sorry for saying this, but I don't like the icons, nor the colored > options (source, bytecode, decompiled, etc.) at the side. I would prefer a > combo on button panel... and better looking icons (yes Stef, FamFam icons is > ok :) > > > I will be really glad to use yours :) You know, I am kind of a programmer. > It means that making icons is not my work. And due to that, it takes me ages > to do them. > I have no problem to change them at all, but I really don't have time to do > them. > so then go finish arts and design schools (min 5 years each). and only then you may get back and continue working on nautilus! Hurry up. :) > 7) Why we have a button panel (which is in fact a toolbar) in the middle of > the browser and not where it belongs: on top? this is a remain of OB, who > took this from old Browser... but conceptually (as in usability terms), this > is a not-good solution. We could think on change this and place the button > bar where it belongs (and add some cool keybindings too) > > > You can't say that the hierarchy button is to far, and ask for putting the > toolbar on top ^^ > It's here because it's close to the lists (where you spend 20% of your time) > and also close to the source code (where you spend 80% of your time). > > 8) different sized buttons are a really bad concept. Yes... in Smalltalk > this is very common: to create buttons with the size of text... but this is > bad design because disrupts harmony, and that hurts to the eyes... and when > something hurts, you try not to use it :) > > > I can't agreeÂ more. But buttons are kind of a pain in the ass (because they > are embedded into a group morph with its own layout etc). As soon as I can > set > vResizing: #rigid; hResizing: #rigid, I'll do it for sure ^^ > > > yeah.. most of my observations are also for any other tool we have, and most > are about usability... I humbly recommend (for all people doing GUIs), the > lecture of this book:Â http://en.wikipedia.org/wiki/Don't_Make_Me_Think.Â It > is for web design, but is also a great guide when you want to make things > people like. > > (Also, reading apple design guide is a good way to notice some interesting > things... those guys had invest an insanely amount of time and money in > development them) > > > I will try to find time to read them, but as I said, my exams are in 11 days > so ;) > no. arts school first. ohh.. nothing is perfect. changes are not always better to what we had. but staying is worst of everything. just keep pushing. I can also easily tell what i don't like in Nautilus. Much harder is to propose alternative. I think that feedback about UI should always come with alternative, explaining why you think its better. Or if one feels that old ways is better he should argument that (an argument 'because i get used to it' is WRONG argument ;). Today i had full day hacking using Nautilus. And found some bugs. Hope next iteration they will be fixed. :) There are some rough corners here and there, but overall impression - it is quite good. I will be starting giving more feedback once i will get used to it. Because 1 day is too little to say anything definitive.. i need more immersion to make my feedback more problem-oriented, not tainted by "i don't like it because it different" attitude. > > Thanks for the feedback :) > -- Best regards, Igor Stasenko.

March 8, 2012