January 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by phil＠highoctane.be

Esteban, Go rest your brain cells... Vacations are always too short! Phil On Mon, Jan 5, 2015 at 9:35 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > probably, but in any case it has to be implemented using existing idioms, > not repeating code, which was the core of my point. > > crap. I really need to turn off my computer or I will continue watching > mails ;) > > Esteban > > On 05 Jan 2015, at 17:25, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > As discussed in this thread, I do not see a reason for implementing this > method in Object. > > Having it in Collection/UndefinedObject can make some sense (although I do > not really like it) for working with variables that can be either > collection or nil. > > Cheers, > Doru > > > > On Mon, Jan 5, 2015 at 8:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> in any case, we already have the idiom #isEmptyOrNil (btw, in pharo4 it >> was removed from Object and I donât know why, but is still in Collection >> and in UndefinedObject). >> So, in case of adding it, the correct implementation should be: >> >> 1) restore Object>>#isEmptyOrNil ^ false >> 2) implement: >> >> Object>>#ifEmptyOrNil: aBlock >> self isEmptyOrNil ifTrue: aBlock. >> ^ self >> >> which IMO is the clean way to implement such idiom. >> >> said that, I will go back to my vacations :) >> >> Esteban >> >> >> >> On 05 Jan 2015, at 15:47, Esteban A. Maringolo <emaringolo(a)gmail.com> >> wrote: >> >> El Mon Jan 05 2015 at 3:36:50 PM, stepharo <stepharo(a)free.fr> escribiÃ³: >> >>> >>> This is not because some people may not know how to program in other >>> languages that we should copy that. >>> >> >> I share your "taste" for this kind of code. >> >> But this purist approach raises the bar leaving out a lot of developers >> with poor design/modelling skills. The more 1:1 mappings they can bring in >> from their previous language of choice, the better, and higher the odds >> they'll clinge on Pharo and continue using it. >> >> To make both "sides" of this discussion happy I think the base image >> shouldn't include this, and there can be an extra package with these >> "language" extensions. >> >> Regards! >> >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > >

Jan. 5, 2015

Re: [Pharo-dev] does anyone have a postal address for Rmod that is suitable for online delivery?

by stepharo

Hi eliot Put Inria - Rmod 40 av de Halley, Parc de la Haute Borne, 59650 Villeneuve d'Ascq - France Le 5/1/15 20:45, Eliot Miranda a Ã©crit : > Hi, > > I need to send something to Rmod. Anyone got an address that shop > bots accept? > > -- > best, > Eliot

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by Esteban Lorenzano

probably, but in any case it has to be implemented using existing idioms, not repeating code, which was the core of my point. crap. I really need to turn off my computer or I will continue watching mails ;) Esteban > On 05 Jan 2015, at 17:25, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > As discussed in this thread, I do not see a reason for implementing this method in Object. > > Having it in Collection/UndefinedObject can make some sense (although I do not really like it) for working with variables that can be either collection or nil. > > Cheers, > Doru > > > > On Mon, Jan 5, 2015 at 8:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > in any case, we already have the idiom #isEmptyOrNil (btw, in pharo4 it was removed from Object and I donât know why, but is still in Collection and in UndefinedObject). > So, in case of adding it, the correct implementation should be: > > 1) restore Object>>#isEmptyOrNil ^ false > 2) implement: > > Object>>#ifEmptyOrNil: aBlock > self isEmptyOrNil ifTrue: aBlock. > ^ self > > which IMO is the clean way to implement such idiom. > > said that, I will go back to my vacations :) > > Esteban > > >> On 05 Jan 2015, at 15:47, Esteban A. Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: >> >> El Mon Jan 05 2015 at 3:36:50 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> escribiÃ³: >> >> This is not because some people may not know how to program in other languages that we should copy that. >> >> I share your "taste" for this kind of code. >> >> But this purist approach raises the bar leaving out a lot of developers with poor design/modelling skills. The more 1:1 mappings they can bring in from their previous language of choice, the better, and higher the odds they'll clinge on Pharo and continue using it. >> >> To make both "sides" of this discussion happy I think the base image shouldn't include this, and there can be an extra package with these "language" extensions. >> >> Regards! >> > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by Tudor Girba

Hi, As discussed in this thread, I do not see a reason for implementing this method in Object. Having it in Collection/UndefinedObject can make some sense (although I do not really like it) for working with variables that can be either collection or nil. Cheers, Doru On Mon, Jan 5, 2015 at 8:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > in any case, we already have the idiom #isEmptyOrNil (btw, in pharo4 it > was removed from Object and I donât know why, but is still in Collection > and in UndefinedObject). > So, in case of adding it, the correct implementation should be: > > 1) restore Object>>#isEmptyOrNil ^ false > 2) implement: > > Object>>#ifEmptyOrNil: aBlock > self isEmptyOrNil ifTrue: aBlock. > ^ self > > which IMO is the clean way to implement such idiom. > > said that, I will go back to my vacations :) > > Esteban > > > > On 05 Jan 2015, at 15:47, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > El Mon Jan 05 2015 at 3:36:50 PM, stepharo <stepharo(a)free.fr> escribiÃ³: > >> >> This is not because some people may not know how to program in other >> languages that we should copy that. >> > > I share your "taste" for this kind of code. > > But this purist approach raises the bar leaving out a lot of developers > with poor design/modelling skills. The more 1:1 mappings they can bring in > from their previous language of choice, the better, and higher the odds > they'll clinge on Pharo and continue using it. > > To make both "sides" of this discussion happy I think the base image > shouldn't include this, and there can be an extra package with these > "language" extensions. > > Regards! > > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by Esteban Lorenzano

in any case, we already have the idiom #isEmptyOrNil (btw, in pharo4 it was removed from Object and I donât know why, but is still in Collection and in UndefinedObject). So, in case of adding it, the correct implementation should be: 1) restore Object>>#isEmptyOrNil ^ false 2) implement: Object>>#ifEmptyOrNil: aBlock self isEmptyOrNil ifTrue: aBlock. ^ self which IMO is the clean way to implement such idiom. said that, I will go back to my vacations :) Esteban > On 05 Jan 2015, at 15:47, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > El Mon Jan 05 2015 at 3:36:50 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> escribiÃ³: > > This is not because some people may not know how to program in other languages that we should copy that. > > I share your "taste" for this kind of code. > > But this purist approach raises the bar leaving out a lot of developers with poor design/modelling skills. The more 1:1 mappings they can bring in from their previous language of choice, the better, and higher the odds they'll clinge on Pharo and continue using it. > > To make both "sides" of this discussion happy I think the base image shouldn't include this, and there can be an extra package with these "language" extensions. > > Regards! >

Jan. 5, 2015

Re: [Pharo-dev] does anyone have a postal address for Rmod that is suitable for online delivery?

by Clara Allende

40 avenue Halley, BÃ¢timent B + office number if you've got it 59650 Villeneuve d'Ascq - France At least I used that one for Amazon shippments... 2015-01-05 16:45 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi, > > I need to send something to Rmod. Anyone got an address that shop > bots accept? > > -- > best, > Eliot >

Jan. 5, 2015

does anyone have a postal address for Rmod that is suitable for online delivery?

by Eliot Miranda

Hi, I need to send something to Rmod. Anyone got an address that shop bots accept? -- best, Eliot

Jan. 5, 2015

Re: [Pharo-dev] The Smalltalk Renaissance Program

by horrido

I just went through a few of the Waveplace videos. I am impressed. They are truly excellent videos and I can see how they can engage youngsters and gently introduce programming concepts to them. Why aren't these being used in Canadian elementary schools??? I shall have to ask. Beyond the early grades, students can continue learning programming with Pharo. I see this as a smooth migration. This is getting exciting! Aaron Rosenzweig wrote > Hi, > > The Squeak images tend to be more tuned towards grade-school education. In > particular, âeToysâ sits on top of smalltalk and is perfect for young > elementary school students to take their first steps in computer > programming. > > My children went through the âwaveplaceâ video tutorials. They did the > beta one which was more in depth and had like 30 videos if I remember > correctly. > > Pharo is more âprofessional.â Not to say there is anything wrong with > Squeak, it was used for DabbleDBâ¦ Itâs just that most developers donât > want to see a mouse with eyeballs following your cursor when you first > launch the image. You can remove that from the image, etc. but itâs that > first feel. > > Overall Squeak seems like it blends in better in the classroom and Pharo > suits developers more. Iâll probably be flamed for saying it but realize > itâs a high level generalization. I know there is more going on underneath > and I know that Pharo is the primary target for Seaside, etc. Both Squeak > and Pharo are nice. > AARON ROSENZWEIG / Chat 'n Bike > e: > aaron@ > t: (301) 956-2319 > > > On Jan 4, 2015, at 5:25 PM, horrido < > horrido.hobbies@ > > wrote: > >> I am intrigued. Where can I find more info about Smalltalk education in >> the >> schools? I want to see what I can do in Canada. >> >> I presume there is a Smalltalk image customized for the classroom and >> aimed >> at elementary school students. That's what I'm hoping for. >> >> >> stepharo wrote >>> ESUG is about the community. Without community then it is terrible. >>> We set up also a program for teachers. Now in the US there is nearly >>> nobody teaching smalltalk and this is a pity. >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797760.h… >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> -- View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797909.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 5, 2015

Re: [Pharo-dev] Wrapping RegQueryValueExA in NativeBoost

by Torsten Bergmann

Hi Vincent, > I succeeded to have a working example. I wrote the code but I can't commit it. Can you add me on the project please? I added the account "VincentBlondeau" to STHub project. You should be able to commit. > Just to give some indications for the code I changed. > > Globally the primitive call is good. But when you pass 'nil' as argument for the primitive, it will not be converted to 'null' ('null' have for value 0). To have the 0, either you change nil into 0 or you add the option #optCoerceNilToNull in the call (because it is not the default...) (See 'NBNativeCodeGen class>>defaultOptions' for the others). It is the mainly problem! But I tried this already. When I - switch to 0 in the calling method #example2 - or switch to 0 directly in the RegQueryValueExA wraper - or use the option optCoerceNilToNull I still get the generic error. > Concerning the arguments allocation there is some tips: > 'NativeBoost allocate: <number>' allocates a memory segment of the size given by <number> and return the address to it. > But it is better to use 'NativeBoost allocate: (NBExternalType sizeOf: 'ulong')' or 'NativeBoost allocate: (NBExternalType sizeOf: 'DWORD')' for both dwType and lSize arguments. Yes, thats clear. I usually try to make it "make it run make it right make it fast", currently I struggle with the first here. ;) > With some advance, you will see in the example4 that the RegQueryValueExA doesn't return a valid error value... I don't know why... Commit the code where the call works and I can check. Step by step ... > I hope it will be helpful, I really appreciate your feedback! Thanks Regards Torsten

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by Esteban A. Maringolo

El Mon Jan 05 2015 at 3:36:50 PM, stepharo <stepharo(a)free.fr> escribiÃ³: > > This is not because some people may not know how to program in other > languages that we should copy that. > I share your "taste" for this kind of code. But this purist approach raises the bar leaving out a lot of developers with poor design/modelling skills. The more 1:1 mappings they can bring in from their previous language of choice, the better, and higher the odds they'll clinge on Pharo and continue using it. To make both "sides" of this discussion happy I think the base image shouldn't include this, and there can be an extra package with these "language" extensions. Regards!

Jan. 5, 2015