November 2013 - Pharo-users

Re: [Pharo-users] PetitParser and external streams

by Sean P. DeNigris

Federico.Balaguer wrote > Hello, > > I am developing a parser with PetitParser and one of the options I would > like to try is to get my parser to read from an external stream (file) and > produce the output to another external stream (another file) > > Is this possible? I found that Stream>>asPetitParser do this: > asPetitStream > ^ self contents asPetitStream > > Thanks! Federico ----- Cheers, Sean -- View this message in context: http://forum.world.st/PetitParser-and-external-streams-tp4721440p4721531.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 12, 2013

Re: [Pharo-users] How to add tabs in Nautilus

by Benjamin

What is exactly your goal ? :) Ben On 12 Nov 2013, at 20:46, kilon alios <kilon.alios(a)gmail.com> wrote: > yeah morphic is quite messy , but hey it works > > Thank you for your effort to bring us a better , cleaner and simpler GUI API. You have my support. I am actually thinking about implementing my own GUI API and I was wondering if I should base it on spec or not. My main focus is custom look guis. But I will wait for the documentation of spec to appear before I make any decision on it. > > > On Tue, Nov 12, 2013 at 9:23 PM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > On 12 Nov 2013, at 19:53, kilon alios <kilon.alios(a)gmail.com> wrote: > >> hahahaha nicely played man , nicely played :D >> >> of course I will , but so you know, I dont pay overtime ... now I think about it, I dont pay at all, but thats another matter . >> >> I would love to see tab in Nautilus , they will definitely sort the windows mess. At least partly. > > Me too :) > Thatâs why I am writing a new one (made with Spec) > > Otherwise, in full morphic, you will see the pain it is :P > > Ben > >> On Tue, Nov 12, 2013 at 8:47 PM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: >> The easier way is to wait for me to finish the new Nautilus with tabs in it :P >> >> Ben >> >> On 12 Nov 2013, at 17:50, kilon alios <kilon.alios(a)gmail.com> wrote: >> >>> I see in the top right side dropdown menu that there is an option to create a window goup which basically add the current instance of Nautilus in a tab but I dont know hot to add other tabs to it. It would be cool to have multiple tabs for each class selection and not to have to open a new window for each one. >>> >>> So how I add other tabs ? >> >> > >

Nov. 12, 2013

Re: [Pharo-users] Current 3.0 download is broken

by Usman Bhatti

I was about to complaint about the issue but good that some people already complained, found the source of the problem and the resolution (sources should be in VM directory and not in image). Good work. The resolution works for me. Now I can revive my pharo settings because I thought the problem was originating from the startup scripts. Usman On Sun, Nov 10, 2013 at 4:48 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > On principle, a big +1 on going forward on the PhD! :-) > > But, the one-click download Pharo3.0-mac.zip being broken is an important > issue that should be addressed fairly quickly in my opinion. As I said, the > sources file should be moved out of Contents/Resources and moved into > Contents/MacOS. Then the one-click also runs. > > On Nov 10, 2013, at 10:29 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > > > On Nov 10, 2013, at 2:05 PM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > > > >> It did not solve the issue yet :/, I will have to look into it next > week. > > > > Don't ;) > > You should not touch Pharo related things and start use pomodoroes to > blast your phd > > > > Stef > >> In any case, I think it would be unrelated to a bootstrap since > FileLocator > >> is already lazily initialized. There is just the typical problem on how > and > >> when to update a singletonâ¦ > > Ok so this is good then. > > > >> > >> I should reopen the issue since the problem persists. > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > >

Nov. 12, 2013

Re: [Pharo-users] Who uses poolDictionaries? New class template cleanup

by StÃ©phane Ducasse

+1 On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > Hi all, > > I am preparing slides for a course. I came to the typical: > > Number subclass: #Complex > instanceVariableNames: 'real imaginary' > classVariableNames: '' > poolDictionaries: '' > category: 'ComplexNumbers' > > Which made me think: Who uses poolDictionaries? I suspect extremely few of us. > > Why not add this to Class: > Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol > ^self subclass: aSymbol > instanceVariableNames: instVarNames > classVariableNames: classVarNames > poolDictionaries: '' > category: aSymbol > > And have the new class template as follows? > > Object subclass: #NameOfSubclass > instanceVariableNames: '' > classVariableNames: '' > category: 'Kernel-Classes' > > It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students. > > Greetings, > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > >

Nov. 12, 2013

Re: [Pharo-users] How to add tabs in Nautilus

by kilon alios

yeah morphic is quite messy , but hey it works Thank you for your effort to bring us a better , cleaner and simpler GUI API. You have my support. I am actually thinking about implementing my own GUI API and I was wondering if I should base it on spec or not. My main focus is custom look guis. But I will wait for the documentation of spec to appear before I make any decision on it. On Tue, Nov 12, 2013 at 9:23 PM, Benjamin < Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > On 12 Nov 2013, at 19:53, kilon alios <kilon.alios(a)gmail.com> wrote: > > hahahaha nicely played man , nicely played :D > > of course I will , but so you know, I dont pay overtime ... now I think > about it, I dont pay at all, but thats another matter . > > I would love to see tab in Nautilus , they will definitely sort the > windows mess. At least partly. > > > Me too :) > Thatâs why I am writing a new one (made with Spec) > > Otherwise, in full morphic, you will see the pain it is :P > > Ben > > On Tue, Nov 12, 2013 at 8:47 PM, Benjamin < > Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > >> The easier way is to wait for me to finish the new Nautilus with tabs in >> it :P >> >> Ben >> >> On 12 Nov 2013, at 17:50, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> I see in the top right side dropdown menu that there is an option to >> create a window goup which basically add the current instance of Nautilus >> in a tab but I dont know hot to add other tabs to it. It would be cool to >> have multiple tabs for each class selection and not to have to open a new >> window for each one. >> >> So how I add other tabs ? >> >> >> > >

Nov. 12, 2013

Re: [Pharo-users] Spec - Layout behaviour when resizing

by Benjamin

Ben On 12 Nov 2013, at 19:46, btc(a)openinworld.com wrote: > Bahman Movaqar wrote: >> On 11/12/2013 17:29, Benjamin wrote: >> >>> On 11 Nov 2013, at 20:08, Bahman Movaqar <Bahman(a)BahmanM.com >>> <mailto:Bahman@BahmanM.com> >> >>> <mailto:Bahman@BahmanM.com>> wrote: >> >>> >> >>>> >> >>>> When a window is resized, every Row/ColumnLayoutdistributes the width >> >>>> and height evenly among any widget or nested layouts it contains. In >> >>>> turn, widgets try to fill as much space as possible. Therefore after >> >>>> resizing text box and button have become so huge and the space >> >>>> between the radio buttons has increased so much. >> >>>> Is that correct? >> >>> >> >>> Itâs correct in the sense it is expected regarding to the layout you >> >>> use :) >> >>> >> >>>> If yes, I have a couple of points to mention: >> >>>> >> >>>> 1. A text box, specially in the case of TextModel and >> >>>> TextInputFieldModel, where it's basically a single line entry >> >>>> (ENTER is not allowed), should not change height (growing width >> >>>> is understandable and desired). The height of a text box >> >>>> (specially a single line one) should only be calculated based on >> >>>> the font family and font size. >> >>>> >> >>> TextModel is for more that one line :) >> >>> TextInputField could eventually be forced to be one line, but I think >> >>> itâs too much of a restriction. >> >> >> >> I am 100% sure I didn't tell TextInputField to accept one line. It >> >> doesn't accept ENTER and I don't understand how a "multi-line" text >> >> entry widget can work without accepting new line character :-) >> >> Yes, TextInputField wraps the text but that's doesn't count as >> >> multi-line entry :-) More importantly it is unexpected behaviour from >> >> user's PoV; I have never seen a single text entry widget wrap the text. >> >> >> >> Or maybe I'm doing something wrong? >> > >> > I do not understand sorry :( >> >> Put in other words: >> 1. The default behaviour (if there's any other behaviour) of a text box in Spec, doesn't accept ENTER. A multi-line text entry without ENTER doesn't make sense, no? What enter does then ? >> 2. The default behaviour of a Spec text box, wraps the text entered if the length exceeds the display length of the widget. This is very unorthodox and wrong *from user's perspective*. What is expected ? Which widget of text ? This behaviour is actually Morphic behaviour, not Spec. But anyway, it can/should be fixed/improved :) > I have to support point 2 above. In general terms... > For a single line text box, I would expect it to scroll text horizontally out of view. > I would expect initially at least two lines for a wrapping text box, after which it can be free to grow vertically as needed. > > cheers -ben >> > >> >> >> >>> >> >>>> 1. >> >>>> >> >>>> >> >>>> >> >>>> 2. A button should not change height and width, unless specifically >> >>>> mentioned otherwise. >> >>>> >> >>> Why ? >> >> >> >> Because if the button changes height/width it loses the visual element >> >> which users use to recognise buttons across a screen. Just like a >> >> single-line text entry, a button's height, if not manually set, is >> >> determined only by the font family and font size. >> >> And regarding changing the button width, I've very rarely seen >> >> applications that resize their buttons when the screen is resized. >> >> Usually people put constraints over this. I'm not stating that this >> >> definitely should be some UI framework's internal mehcanism. Perhaps a >> >> simple method like `isCalculatedSize: aBoolean` with a TRUE default is >> >> enough. >> > >> > Thatâs true changing the size is often not desired. >> > >> > Adding a flag can be a solution :) >> > But as it brings some more complexity in the layouting ( which is already > quite too complex and too big) it was not considered until now :) >> >> Makes sense. >> >> > >> >> >> >>>> 3. It's not usually desirable that the spacing between radio buttons >> >>>> change. >> >>>> >> >>> Thatâs true :) >> >>> But how to know that two radio buttons are close one to the other ? >> >> >> >> Right. That's the reason radio button groups are, AFAIK, always >> >> implemented as widgets. >> > >> > Yes, but morphic do not do that :P >> > Myabe I should introduce a model for that, and have my own encapsulation :) >> >> Perfect idea. And along with some documentation please :-D >> >> > >> >> >> >>> >> >>>> 4. Usually there's a way to specify how to distribute the >> >>>> width/height between layouts and widgets inside a layout (usually >> >>>> based on a percentage). >> >>>> >> >>> There in spec as well :) >> >>> You can have a look at: >> >>> add:origin:corner:offsetOrigin:offsetCorner: >> >>> >> >> Hmm...couldn't figure out the logic. Though it seems simple when >> >> looking at the code :-) >> > >> > Here you entrer in some twilight zone :P >> > >> > add:origin:corner:offsetOrigin:offsetCorner: >> > >> > >> > This screen shows an origin in x0,y0 and a corner in x1,y1. >> > Their values are between 0 and 1, and represent a _proportional_ value of the > container. >> >> By the gods! How was I supposed to know the values were supposed to be 0><1 !? :-) Thank you for this tip! Everybody should know that :P >> >> > >> > Then, each of this corners can be shifted in x and y by a _fixed_ value (in > pixels) >> >> So basically `add: #buttonGreet origin: 0.3(a)0.2 corner: 0.7(a)0.5 offsetOrigin: 0@0 offsetCorner: 0@0` would add a button in a center'ish position within its container, right? It should do something like this yes :) >> I wonder what am I doing wrong since it has no effect whatsoever? What is the result ? Ben >> >> Thanks, >> >> -- >> Bahman Movaqar (http://BahmanM.com) >> >> ERP Evaluation, Implementation & Deployment Consultant >> PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) >> >> > > >

Nov. 12, 2013

Re: [Pharo-users] How to add tabs in Nautilus

by Benjamin

On 12 Nov 2013, at 19:53, kilon alios <kilon.alios(a)gmail.com> wrote: > hahahaha nicely played man , nicely played :D > > of course I will , but so you know, I dont pay overtime ... now I think about it, I dont pay at all, but thats another matter . > > I would love to see tab in Nautilus , they will definitely sort the windows mess. At least partly. Me too :) Thatâs why I am writing a new one (made with Spec) Otherwise, in full morphic, you will see the pain it is :P Ben > On Tue, Nov 12, 2013 at 8:47 PM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > The easier way is to wait for me to finish the new Nautilus with tabs in it :P > > Ben > > On 12 Nov 2013, at 17:50, kilon alios <kilon.alios(a)gmail.com> wrote: > >> I see in the top right side dropdown menu that there is an option to create a window goup which basically add the current instance of Nautilus in a tab but I dont know hot to add other tabs to it. It would be cool to have multiple tabs for each class selection and not to have to open a new window for each one. >> >> So how I add other tabs ? > >

Nov. 12, 2013

Re: [Pharo-users] How to add tabs in Nautilus

by kilon alios

hahahaha nicely played man , nicely played :D of course I will , but so you know, I dont pay overtime ... now I think about it, I dont pay at all, but thats another matter . I would love to see tab in Nautilus , they will definitely sort the windows mess. At least partly. On Tue, Nov 12, 2013 at 8:47 PM, Benjamin < Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > The easier way is to wait for me to finish the new Nautilus with tabs in > it :P > > Ben > > On 12 Nov 2013, at 17:50, kilon alios <kilon.alios(a)gmail.com> wrote: > > I see in the top right side dropdown menu that there is an option to > create a window goup which basically add the current instance of Nautilus > in a tab but I dont know hot to add other tabs to it. It would be cool to > have multiple tabs for each class selection and not to have to open a new > window for each one. > > So how I add other tabs ? > > >

Nov. 12, 2013

Re: [Pharo-users] How to add tabs in Nautilus

by Benjamin

The easier way is to wait for me to finish the new Nautilus with tabs in it :P Ben On 12 Nov 2013, at 17:50, kilon alios <kilon.alios(a)gmail.com> wrote: > I see in the top right side dropdown menu that there is an option to create a window goup which basically add the current instance of Nautilus in a tab but I dont know hot to add other tabs to it. It would be cool to have multiple tabs for each class selection and not to have to open a new window for each one. > > So how I add other tabs ?

Nov. 12, 2013

Re: [Pharo-users] Spec - Layout behaviour when resizing

by btc＠openinworld.com

Bahman Movaqar wrote: > On 11/12/2013 17:29, Benjamin wrote: > >>> On 11 Nov 2013, at 20:08, Bahman Movaqar <Bahman(a)BahmanM.com > >>> <mailto:Bahman@BahmanM.com> > >>> <mailto:Bahman@BahmanM.com>> wrote: > >>> > >>>> > >>>> When a window is resized, every Row/ColumnLayoutdistributes the width > >>>> and height evenly among any widget or nested layouts it contains. In > >>>> turn, widgets try to fill as much space as possible. Therefore after > >>>> resizing text box and button have become so huge and the space > >>>> between the radio buttons has increased so much. > >>>> Is that correct? > >>> > >>> Itâs correct in the sense it is expected regarding to the layout you > >>> use :) > >>> > >>>> If yes, I have a couple of points to mention: > >>>> > >>>> 1. A text box, specially in the case of TextModel and > >>>> TextInputFieldModel, where it's basically a single line entry > >>>> (ENTER is not allowed), should not change height (growing width > >>>> is understandable and desired). The height of a text box > >>>> (specially a single line one) should only be calculated based on > >>>> the font family and font size. > >>>> > >>> TextModel is for more that one line :) > >>> TextInputField could eventually be forced to be one line, but I think > >>> itâs too much of a restriction. > >> > >> I am 100% sure I didn't tell TextInputField to accept one line. It > >> doesn't accept ENTER and I don't understand how a "multi-line" text > >> entry widget can work without accepting new line character :-) > >> Yes, TextInputField wraps the text but that's doesn't count as > >> multi-line entry :-) More importantly it is unexpected behaviour from > >> user's PoV; I have never seen a single text entry widget wrap the text. > >> > >> Or maybe I'm doing something wrong? > > > > I do not understand sorry :( > > Put in other words: > 1. The default behaviour (if there's any other behaviour) of a text box in > Spec, doesn't accept ENTER. A multi-line text entry without ENTER doesn't make > sense, no? > 2. The default behaviour of a Spec text box, wraps the text entered if the > length exceeds the display length of the widget. This is very unorthodox and > wrong *from user's perspective*. > I have to support point 2 above. In general terms... For a single line text box, I would expect it to scroll text horizontally out of view. I would expect initially at least two lines for a wrapping text box, after which it can be free to grow vertically as needed. cheers -ben > > > >> > >>> > >>>> 1. > >>>> > >>>> > >>>> > >>>> 2. A button should not change height and width, unless specifically > >>>> mentioned otherwise. > >>>> > >>> Why ? > >> > >> Because if the button changes height/width it loses the visual element > >> which users use to recognise buttons across a screen. Just like a > >> single-line text entry, a button's height, if not manually set, is > >> determined only by the font family and font size. > >> And regarding changing the button width, I've very rarely seen > >> applications that resize their buttons when the screen is resized. > >> Usually people put constraints over this. I'm not stating that this > >> definitely should be some UI framework's internal mehcanism. Perhaps a > >> simple method like `isCalculatedSize: aBoolean` with a TRUE default is > >> enough. > > > > Thatâs true changing the size is often not desired. > > > > Adding a flag can be a solution :) > > But as it brings some more complexity in the layouting ( which is already > > quite too complex and too big) it was not considered until now :) > > Makes sense. > > > > >> > >>>> 3. It's not usually desirable that the spacing between radio buttons > >>>> change. > >>>> > >>> Thatâs true :) > >>> But how to know that two radio buttons are close one to the other ? > >> > >> Right. That's the reason radio button groups are, AFAIK, always > >> implemented as widgets. > > > > Yes, but morphic do not do that :P > > Myabe I should introduce a model for that, and have my own encapsulation :) > > Perfect idea. And along with some documentation please :-D > > > > >> > >>> > >>>> 4. Usually there's a way to specify how to distribute the > >>>> width/height between layouts and widgets inside a layout (usually > >>>> based on a percentage). > >>>> > >>> There in spec as well :) > >>> You can have a look at: > >>> add:origin:corner:offsetOrigin:offsetCorner: > >>> > >> Hmm...couldn't figure out the logic. Though it seems simple when > >> looking at the code :-) > > > > Here you entrer in some twilight zone :P > > > > add:origin:corner:offsetOrigin:offsetCorner: > > > > > > This screen shows an origin in x0,y0 and a corner in x1,y1. > > Their values are between 0 and 1, and represent a _proportional_ value of the > > container. > > By the gods! How was I supposed to know the values were supposed to be 0><1 !? > :-) Thank you for this tip! > > > > > Then, each of this corners can be shifted in x and y by a _fixed_ value (in > > pixels) > > So basically `add: #buttonGreet origin: 0.3(a)0.2 corner: 0.7(a)0.5 offsetOrigin: > 0@0 offsetCorner: 0@0` would add a button in a center'ish position within its > container, right? > I wonder what am I doing wrong since it has no effect whatsoever? > > Thanks, > > -- > Bahman Movaqar (http://BahmanM.com) > > ERP Evaluation, Implementation & Deployment Consultant > PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) > >

Nov. 12, 2013