August 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Unintuitive behavior of class-side initialize

by Ignacio Sniechowski

thanks, Im familiar with pillar as incontributed some stuff for the pharo for the enterprise. I will take a look. Also Thanks for your video tutorials, they are really awesome. Please please continue to add more. Take care Nacho Enviado desde Molto para iPad De: kilon alios Enviado: jueves, agosto 28, 2014 08:02 a.m. Para: Any question about pharo is welcome Asunto: Re: [Pharo-users] Unintuitive behavior of class-side initialize you can read the book here https://www.gitbook.io/book/kilon/pbe main repo is here https://github.com/SquareBracketAssociates/UpdatedPharoByExample Sure exercises are always a good idea. We use pillar syntax which is quite simple, drop off to irc chat #Pharo at freenode to discuss the detail though most things are already well documented about the process of contributing to the book.Â I have ported so far 4 chapter and I am in chapter 5 , Damien has port one chapter and Stephan partly ported another so we around 50% of the book.Â On Thu, Aug 28, 2014 at 1:51 PM, Ignacio Sniechowski <0800nacho(a)gmail.com> wrote: Kilon, Do you have a preview version of the updated book? I would love to see it. Also would you consider adding some exercises will be a good addition? I think so....let me know and i guess i can merge the project i've started to the updated book. Best Nacho Enviado desde Molto para iPad De: kilon alios Enviado: miÃ©rcoles, agosto 27, 2014 09:50 a.m. Para: Any question about pharo is welcome Asunto: Re: [Pharo-users] Unintuitive behavior of class-side initialize I will be adding an "Introduction to Object Orientation" chapter to the new updated Pharo By Example online book, so I will add this to the chapter. The chapter will target people not familiar with Object Orientation and people new to coding. Its not an immediate target but it will happen till the end of the year. Â Â On Wed, Aug 27, 2014 at 3:44 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: On Wed, Aug 27, 2014 at 8:22 AM, webwarrior <reg(a)webwarrior.ws> wrote: As class is just an object in Smalltalk, it would be reasonable to believe that #initialize message is always sent to class on creation. However, that's not true. It is only sent to classes that redefine #initialize. Also sending super initialize may lead to problems. Ohhh yes. There is always a time for every Smalltalkers where you discover that doing super for class side initialize is not a good idea. Here was my time:Â http://forum.world.st/super-initialize-is-not-a-good-idea-for-Behaviors-td3… Â None of these is mentioned in documentation (I assume Pahro By Example is the official one). It only says that #initialize is sent when class is loaded into memory. I think either this behavior should be made more consistent, or excplicitly mentioned in the docs. +1 to the documentationÂ Â -- View this message in context: http://forum.world.st/Unintuitive-behavior-of-class-side-initialize-tp47750… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- Mariano http://marianopeck.wordpress.com

Aug. 28, 2014

Re: [Pharo-users] Unintuitive behavior of class-side initialize

by kilon alios

you can read the book here https://www.gitbook.io/book/kilon/pbe main repo is here https://github.com/SquareBracketAssociates/UpdatedPharoByExample Sure exercises are always a good idea. We use pillar syntax which is quite simple, drop off to irc chat #Pharo at freenode to discuss the detail though most things are already well documented about the process of contributing to the book. I have ported so far 4 chapter and I am in chapter 5 , Damien has port one chapter and Stephan partly ported another so we around 50% of the book. On Thu, Aug 28, 2014 at 1:51 PM, Ignacio Sniechowski <0800nacho(a)gmail.com> wrote: > Kilon, > Do you have a preview version of the updated book? > I would love to see it. > Also would you consider adding some exercises will be a good addition? I > think so....let me know and i guess i can merge the project i've started to > the updated book. > Best > Nacho > > Enviado desde Molto <http://www.moltoapp.com/app?tag=ipad_sig> para iPad > > De: kilon alios > Enviado: miÃ©rcoles, agosto 27, 2014 09:50 a.m. > Para: Any question about pharo is welcome > Asunto: Re: [Pharo-users] Unintuitive behavior of class-side initialize > > I will be adding an "Introduction to Object Orientation" chapter to the > new updated Pharo By Example online book, so I will add this to the > chapter. The chapter will target people not familiar with Object > Orientation and people new to coding. Its not an immediate target but it > will happen till the end of the year. > > > On Wed, Aug 27, 2014 at 3:44 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> >> On Wed, Aug 27, 2014 at 8:22 AM, webwarrior <reg(a)webwarrior.ws> wrote: >> >>> As class is just an object in Smalltalk, it would be reasonable to >>> believe >>> that #initialize message is always sent to class on creation. >>> >>> However, that's not true. It is only sent to classes that redefine >>> #initialize. Also sending super initialize may lead to problems. >>> >>> >> Ohhh yes. There is always a time for every Smalltalkers where you >> discover that doing super for class side initialize is not a good idea. >> Here was my time: >> http://forum.world.st/super-initialize-is-not-a-good-idea-for-Behaviors-td3… >> >> >>> None of these is mentioned in documentation (I assume Pahro By Example is >>> the official one). It only says that #initialize is sent when class is >>> loaded into memory. >>> >>> I think either this behavior should be made more consistent, or >>> excplicitly >>> mentioned in the docs. >>> >> >> >> +1 to the documentation >> >> >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Unintuitive-behavior-of-class-side-initialize-tp47750… >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > >

Aug. 28, 2014

Re: [Pharo-users] Unintuitive behavior of class-side initialize

by Ignacio Sniechowski

Kilon, Do you have a preview version of the updated book? I would love to see it. Also would you consider adding some exercises will be a good addition? I think so....let me know and i guess i can merge the project i've started to the updated book. Best Nacho Enviado desde Molto para iPad De: kilon alios Enviado: miÃ©rcoles, agosto 27, 2014 09:50 a.m. Para: Any question about pharo is welcome Asunto: Re: [Pharo-users] Unintuitive behavior of class-side initialize I will be adding an "Introduction to Object Orientation" chapter to the new updated Pharo By Example online book, so I will add this to the chapter. The chapter will target people not familiar with Object Orientation and people new to coding. Its not an immediate target but it will happen till the end of the year. Â Â On Wed, Aug 27, 2014 at 3:44 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: On Wed, Aug 27, 2014 at 8:22 AM, webwarrior <reg(a)webwarrior.ws> wrote: As class is just an object in Smalltalk, it would be reasonable to believe that #initialize message is always sent to class on creation. However, that's not true. It is only sent to classes that redefine #initialize. Also sending super initialize may lead to problems. Ohhh yes. There is always a time for every Smalltalkers where you discover that doing super for class side initialize is not a good idea. Here was my time:Â http://forum.world.st/super-initialize-is-not-a-good-idea-for-Behaviors-td3… Â None of these is mentioned in documentation (I assume Pahro By Example is the official one). It only says that #initialize is sent when class is loaded into memory. I think either this behavior should be made more consistent, or excplicitly mentioned in the docs. +1 to the documentationÂ Â -- View this message in context: http://forum.world.st/Unintuitive-behavior-of-class-side-initialize-tp47750… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- Mariano http://marianopeck.wordpress.com

Aug. 28, 2014

Re: [Pharo-users] [ANN] Teapot 0.8 micro web framework

by S Krish

Thanks for the observation. In the age of text chats and SMS, not that I do either of them, we forget the art of writing well. On Thu, Aug 28, 2014 at 2:34 PM, Ben Coman <btc(a)openinworld.com> wrote: > I haven't the time play with it right now, but its a good read. Just > some minor grammar feedback... > > > you are quicker off the block > you are quickly off the block > > > This also provides a flexibility in scaling > This also provides flexibility in scaling > > cheers -ben > > S Krish wrote: > > > The framework is nice.. and addictive to play with as stated before, well > documented, clean and easy.. ! > > Potentially a good tool to weave into any app. My quick play with the > framework, surprised me with its productive usage.. so here it goes.. > Teapot: Pharo web REST framework, it ainât micro > <https://skrishnamachari.wordpress.com/2014/08/28/teapot-pharo-web-rest-fram…> > > > On Mon, Aug 25, 2014 at 11:06 PM, Attila Magyar <m.magyar3(a)gmail.com> > wrote: > >> Santiago Bragagnolo wrote >> >> I played a little bit with Teapot last week during ESUG and was >> wondering >> >> what is your flow when you are designing/experimenting an API with >> >> Teapot? >> >> Do you reset the instance everytime you modify/add a route? >> >> I'm not sure i understand it correctly. The routes are stored in a >> router in >> an OrderedCollection. If you say >> >> teapot >> GET: '/foo/bar' -> someAction >> >> A new Route will be created with the given url pattern, action, http >> method >> and default response transformer. The first 3 things cannot be modifed >> later, but the response transformer can. So if you say: >> >> teapot >> GET: '/foo/bar' -> someAction; output: #ston >> >> Then the ston transformer will be added to the current route, after the >> route was added to the router. Teapot stores a reference to the current >> route to be able to do this. In the future there may be other messages >> (eg. >> filtering based on the content-type or other request properties). The >> reason >> for doing this is to avoid the combinatorial explosion of method numbers >> (there is no need to implement GET:output:, POST:output:, etc..). >> >> Is it an answer for your question or did you mean something else? >> >> >> >> -- >> View this message in context: >> http://forum.world.st/ANN-Teapot-0-8-micro-web-framework-tp4774449p4774693.… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> > >

Aug. 28, 2014

Re: [Pharo-users] [ANN] Teapot 0.8 micro web framework

by Ben Coman

Aug. 28, 2014

Re: [Pharo-users] [ANN] Teapot 0.8 micro web framework

by S Krish

The framework is nice.. and addictive to play with as stated before, well documented, clean and easy.. ! Potentially a good tool to weave into any app. My quick play with the framework, surprised me with its productive usage.. so here it goes.. Teapot: Pharo web REST framework, it ainât micro <https://skrishnamachari.wordpress.com/2014/08/28/teapot-pharo-web-rest-fram…> On Mon, Aug 25, 2014 at 11:06 PM, Attila Magyar <m.magyar3(a)gmail.com> wrote: > Santiago Bragagnolo wrote > >> I played a little bit with Teapot last week during ESUG and was > wondering > >> what is your flow when you are designing/experimenting an API with > >> Teapot? > >> Do you reset the instance everytime you modify/add a route? > > I'm not sure i understand it correctly. The routes are stored in a router > in > an OrderedCollection. If you say > > teapot > GET: '/foo/bar' -> someAction > > A new Route will be created with the given url pattern, action, http method > and default response transformer. The first 3 things cannot be modifed > later, but the response transformer can. So if you say: > > teapot > GET: '/foo/bar' -> someAction; output: #ston > > Then the ston transformer will be added to the current route, after the > route was added to the router. Teapot stores a reference to the current > route to be able to do this. In the future there may be other messages (eg. > filtering based on the content-type or other request properties). The > reason > for doing this is to avoid the combinatorial explosion of method numbers > (there is no need to implement GET:output:, POST:output:, etc..). > > Is it an answer for your question or did you mean something else? > > > > -- > View this message in context: > http://forum.world.st/ANN-Teapot-0-8-micro-web-framework-tp4774449p4774693.… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Aug. 28, 2014

Re: [Pharo-users] Persistence on Moose browsers, showing always a selection in trees and making tree labels editable.

by Offray Vladimir Luna CÃ¡rdenas

Hi Doru, Sven and community, I have made a small experiment to get persistence on browsers by using STON. I really like the readability of STON. At [1] you can see a screen shoot of a moose browser tree and attached to this mail is equivalent STON file. [1] http://www.enlightenment.org/ss/e-53febbe8656192.95414052.jpg I have some questions, nothing with code because they're kind of general and not referred to any particular code written at the moment. Any way if someone want to see the code and load the browser, here is what needs to be done: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gofer new smalltalkhubUser: 'Offray' project: 'Ubakye'; package: 'Ubakye'; load. UbakyeBrowser open. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Here are the questions: I would like to capture some events that happens in panels. For example, suppose I write a text in the "Cuerpo | Body" panel and I would like to get the body of my node updated with what has been wrote on the panel. I have seen "Populate port action" example, but it works on selection and I would like to update the tree anytime a body panel is wrote, without any particular selection and also the "updateOn" message, but I don't know if this is the proper message to use when the user is just writing in a text panel of a moose browser. How can I updating on writing in a text panel can be done? Also, how can I create an emergent window (similar to the inspector example that Doru gave to me) but just with the current name of the header of the node, and also made that the node header updates on clicking "Ok" button of that emergent Window? The last question its related with Sven's STON: Suppose that I would like to store light markup languages in STON which have the single quote character (') on them, without creating any escape sequence, is this possible on STON and if not, what is needed to be changed for that? Thanks, Offray On 08/20/2014 03:08 AM, Tudor Girba wrote: > Hi, > > > On Wed, Aug 20, 2014 at 5:38 AM, Offray Vladimir Luna CÃ¡rdenas > <offray(a)riseup.net <mailto:offray@riseup.net>> wrote: > > Hi, > > With the valuable help of the community and the GLMBasicExamples I have been > able to build basic outlining interface and functionality. Here is a screenshot: > > http://www.enlightenment.org/__ss/e-53f4243a4dc127.49773492.__jpg > <http://www.enlightenment.org/ss/e-53f4243a4dc127.49773492.jpg> > > There are some issues: > > 1. Now I would like to make the nodes in the tree persistent in the sense > that if I wrote something in the node body (left upper part of the browser) > and I select another node, when I visit the previous node, the text in the > body still is there. How can I do this? > > > I believe you refer to some sort of automatic saving. This is not possible at > the moment, but it would certainly cool to get added :( > > 2. I would like to make the current node always selected by this blue > highlighting. With some operations like moving nodes to the left or to the > right, the current node gets out of focus, despite of the operations being > done over it. There is any way to say Moose browsers where to put the > selections, besides of explicit selection with the mouse. > > > You can just set the #selection or the #selectionPath ports. > > 3. Some time ago I asked about how to make tree labels (headers), at the > left of the browsers editable. There is any way to make this? > > > No :(. But, again, it would be cool to get this support. > > Cheers, > Doru > > Thanks a lot, > > Offray > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" >

Aug. 28, 2014

Re: [Pharo-users] Pharo on Nvidia Jetson TK1?

by kilon alios

There is a chance if you are able to run Pharo on that platform and support python wrappers for CUDA (python is already support for CUDA for regular nvidia GPUs but I dont know about this platform ) you could use my Atlas lib to access Cuda from Pharo. Atlas is a library I am making that allows you to use Python libraries from Pharo and its code I use for my project Ephestos to control Blender the 3d app. Not as cool or powerful / flexible as having an actual Pharo wrapper but it could be a good replacement till such library arrives. There is also Pharo wrappers for OpenCL by another Pharo developer , if this platform support OpenCL (it seems that it currently it does not) it may be possible to modify the wrappers to support this platform as well. On Wed, Aug 27, 2014 at 11:29 PM, volkert(a)nivoba.de <volkert(a)nivoba.de> wrote: > Wouldn't this a nice platform for Pharo? I mean a Pharo with full CUDA and > OpenGL Support ... i would like it. :-) > > https://developer.nvidia.com/jetson-tk1 > http://devblogs.nvidia.com/parallelforall/jetson-tk1- > mobile-embedded-supercomputer-cuda-everywhere/ > http://elinux.org/Jetson_TK1 > http://developer.download.nvidia.com/embedded/jetson/ > TK1/docs/Jetson_platform_brief_May2014.pdf > https://www.youtube.com/watch?v=9teSvCL0NX0 > https://www.youtube.com/watch?v=YfUHei3M0Jw > > BW, > Volkert > > -- > www.nivoba.de > > "The more complex an object, the larger the investment in learning to use > it, and the greater the resistance to abandon it.", NW > > >

Aug. 27, 2014

Re: [Pharo-users] Pharo on Nvidia Jetson TK1?

by stepharo

On 27/8/14 22:29, volkert(a)nivoba.de wrote: > Wouldn't this a nice platform for Pharo? I mean a Pharo with full CUDA > and OpenGL Support ... i would like it. :-) me too but time/money... for the OpenGL support there is already a part. > > https://developer.nvidia.com/jetson-tk1 > http://devblogs.nvidia.com/parallelforall/jetson-tk1-mobile-embedded-superc… > > http://elinux.org/Jetson_TK1 > http://developer.download.nvidia.com/embedded/jetson/TK1/docs/Jetson_platfo… > > https://www.youtube.com/watch?v=9teSvCL0NX0 > https://www.youtube.com/watch?v=YfUHei3M0Jw > > BW, > Volkert >

Aug. 27, 2014

Pharo on Nvidia Jetson TK1?

by volkert＠nivoba.de

Wouldn't this a nice platform for Pharo? I mean a Pharo with full CUDA and OpenGL Support ... i would like it. :-) https://developer.nvidia.com/jetson-tk1 http://devblogs.nvidia.com/parallelforall/jetson-tk1-mobile-embedded-superc… http://elinux.org/Jetson_TK1 http://developer.download.nvidia.com/embedded/jetson/TK1/docs/Jetson_platfo… https://www.youtube.com/watch?v=9teSvCL0NX0 https://www.youtube.com/watch?v=YfUHei3M0Jw BW, Volkert -- www.nivoba.de "The more complex an object, the larger the investment in learning to use it, and the greater the resistance to abandon it.", NW

Aug. 27, 2014