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

Re: [Pharo-users] Another Pharo based solution released

by Johan Fabry

Cool, congratulations! Time for a âsuccess storyâ on the website? On Jun 9, 2014, at 2:22 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Last Friday my company released a new software solution that involves > Pharo in the server side. > > It consists of a Android based app running on tablets, used for the > showcase and sales of products during expos (of retail companies), > backed by a Pharo server through a REST API, and with a Seaside based > admin/users web. > > The first expo was during the last weekend (fri-sun), and it involved > the sales of a large number of orders and products (I can't disclose > the numbers). > The scale of the solution/user base is small, far from being "cloud > scale", but it is for one of the largest consumer goods manufacturer > (and the one who sold the most during the expo). > Anyhow, the server handled all the request perfectly, without a single glitch. > > We already have some future expos scheduled. So it will continue to > run along the already running Pharo based solution in the same > company. > > Best regards! > > Esteban A. Maringolo > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

June 9, 2014

Another Pharo based solution released

by Esteban A. Maringolo

Last Friday my company released a new software solution that involves Pharo in the server side. It consists of a Android based app running on tablets, used for the showcase and sales of products during expos (of retail companies), backed by a Pharo server through a REST API, and with a Seaside based admin/users web. The first expo was during the last weekend (fri-sun), and it involved the sales of a large number of orders and products (I can't disclose the numbers). The scale of the solution/user base is small, far from being "cloud scale", but it is for one of the largest consumer goods manufacturer (and the one who sold the most during the expo). Anyhow, the server handled all the request perfectly, without a single glitch. We already have some future expos scheduled. So it will continue to run along the already running Pharo based solution in the same company. Best regards! Esteban A. Maringolo

June 9, 2014

Re: [Pharo-users] Slots

by Johan Fabry

On Jun 9, 2014, at 8:28 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > In general, I do not think that we should make Pharo more static. To the extreme opposite, we should explore what a dynamic > (reflective, late bound) system can do that a static one can not doâ¦ and this means actually using the dynamic features > (in a controlled way) even in deployment. +1 on that. The dynamism of Smalltalk always and forever is a powerful too that we should not have to do without. > Of course this might mean that we can not be everything for everyone. But do we really want that? E.g. Is it the goal to be > a perfect development system for todayâs resource constrained mircro controllers? Or should we not better explore what the > new embedded world that already starts to show will get from a more dynamic point of view? In the super constrained micro controllers development is typically some C-like thingy (hacked together), we should not try to change those customs and that culture, thatâs not realistic. The new embedded world is indeed the place to go. For example, the raspberry pi running Pharo, that kind of hardware is becoming really wide-spread now. Other example is the Parrot AR Drone quadcopter, thatâs a FLYING embedded system that has a 32 bit ARM Cortex A8 processor @ 800MHz, 1GB DDR2 RAM, WIFI and runs Linux 2.6.x. â¦ while it is flying â¦ Now thatâs cool! :-) > The real challenge of embedded is the embedded nature, we now see a class of embedded systems that have *real* resources > and that are actually always network connected. > Here we can (we must!) take a complete different point of view to the standard âas static as possible, we have no resourcesâ view that > people focus on now. Even the parrot drone is always network connected â¦ its remote control is over wifi :-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

June 9, 2014

Re: [Pharo-users] Emails

by Bernat Romagosa

Check out world.st, all smalltalk lists are accessible there in a forum-like fashion. On Jun 9, 2014 3:25 PM, "Bob Williams" <rwilliams19(a)cox.net> wrote: > This may sound stupid, but I want to answer a specific email and all I > have is the Pharo-user Digest. When I started following Pharo I had a link > to a Web page that showed the emails by subject and author; however, I seem > to have lost that link. All I have now is the digest and the archives. Can > anyone help me? >

June 9, 2014

Emails

by Bob Williams

This may sound stupid, but I want to answer a specific email and all I have is the Pharo-user Digest. When I started following Pharo I had a link to a Web page that showed the emails by subject and author; however, I seem to have lost that link. All I have now is the digest and the archives. Can anyone help me?

June 9, 2014

Re: [Pharo-users] Slots

by Marcus Denker

On 09 Jun 2014, at 14:20, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 09 Jun 2014, at 13:55, Bob Williams <rwilliams19(a)cox.net> wrote: > >> Camille and Marcus, thank you for your response. I thought something was missing, so the testing of Slots will be shelved for now; however, while it is in the planning stage, I would like to add some thoughts on targets and deliverable products (applications). >> >> I agree that most devices like the iPad and iPhone would not be suitable for development, they should be targets for application development and I would expand that list to include all devices, even micro-controllers. Look at the development process for the iPad and iPhone, the programming is done on a Mac using Xcode and testing is done first on the simulator running on the Mac and latter on the actual device. I find the Xcode environment inferior to Smalltalk's and by no stretch of the imagination is Objective-C a good substitute for Smalltalk. I think that development of application programs could be done far better with Smalltalk, provided that some tools were added to Smalltalk. Why not have the view, if it can be programmed in C then it can be programmed in Smalltalk. >> >> I think that the application process should be viewed as a series of steps culminating in the production of a product for sale or distribution: develop and test the program logic, test using constraints imposed by the target device, performance testing, test on the target device, and package for sale or distribution. A good examples of the second step where the constraints of the target is imposed are the word size and floating-point precision differences found in the target. If the development of the application is on a 64-bit computer then integer and floating-point calculated must be simulated for targets with smaller word size and for 32-bit floating-point or no floating-point processor. >> >> Implicit in those steps is the notion a gradual typing, the first uses the Smalltalk model to generically test the logic of the program, while the final step would require a fully compiled executable for some of the targets. I would argue that one reason that Smalltalk was not a commercial success was that you could not provide a fully compiled executable to the customer. The tools that the Smalltalk environment provides makes it a very productive application development environment, but of what use are they to the end user of the application, say a clerk or a business executive: why should any of the development tools be in the final product? >> >> It is clear that Slots will be used in the enforcement of typing at the instance variable level, but what about temporary variables? Can a compiler (machine not bytecode) be developed if temporary variables are not typed? Then there is the question of how to handle the elements of heterogeneous collections. >> >> I have more thoughts, but the above are related to Slots. Any comments? >> > > I donât think that the main power of Slots if typingâ¦ its more slots with behavioural changes or meta data. > Slots can be used for providing typed slots, but these would just do a runtime check, slowing down everything. > Itâs much more interesting for things like ProperySlots, BooleanSlots (which would be very memory efficient, typing > would be just a side effect). > > For typing, the actually annotations (of ivars, temps, and casting of expressions, return typesâ¦) is not that problemâ¦designing > a good type system is the real thing, e.g.: > > http://rmod.inria.fr/web/publications/bib?query=Alle13a&display=abstract > In general, I do not think that we should make Pharo more static. To the extreme opposite, we should explore what a dynamic (reflective, late bound) system can do that a static one can not doâ¦ and this means actually using the dynamic features (in a controlled way) even in deployment. Of course this might mean that we can not be everything for everyone. But do we really want that? E.g. Is it the goal to be a perfect development system for todayâs resource constrained mircro controllers? Or should we not better explore what the new embedded world that already starts to show will get from a more dynamic point of view? The real challenge of embedded is the embedded nature, we now see a class of embedded systems that have *real* resources and that are actually always network connected. Here we can (we must!) take a complete different point of view to the standard âas static as possible, we have no resourcesâ view that people focus on now. Marcus

June 9, 2014

Re: [Pharo-users] Slots

by Marcus Denker

On 09 Jun 2014, at 13:55, Bob Williams <rwilliams19(a)cox.net> wrote: > Camille and Marcus, thank you for your response. I thought something was missing, so the testing of Slots will be shelved for now; however, while it is in the planning stage, I would like to add some thoughts on targets and deliverable products (applications). > > I agree that most devices like the iPad and iPhone would not be suitable for development, they should be targets for application development and I would expand that list to include all devices, even micro-controllers. Look at the development process for the iPad and iPhone, the programming is done on a Mac using Xcode and testing is done first on the simulator running on the Mac and latter on the actual device. I find the Xcode environment inferior to Smalltalk's and by no stretch of the imagination is Objective-C a good substitute for Smalltalk. I think that development of application programs could be done far better with Smalltalk, provided that some tools were added to Smalltalk. Why not have the view, if it can be programmed in C then it can be programmed in Smalltalk. > > I think that the application process should be viewed as a series of steps culminating in the production of a product for sale or distribution: develop and test the program logic, test using constraints imposed by the target device, performance testing, test on the target device, and package for sale or distribution. A good examples of the second step where the constraints of the target is imposed are the word size and floating-point precision differences found in the target. If the development of the application is on a 64-bit computer then integer and floating-point calculated must be simulated for targets with smaller word size and for 32-bit floating-point or no floating-point processor. > > Implicit in those steps is the notion a gradual typing, the first uses the Smalltalk model to generically test the logic of the program, while the final step would require a fully compiled executable for some of the targets. I would argue that one reason that Smalltalk was not a commercial success was that you could not provide a fully compiled executable to the customer. The tools that the Smalltalk environment provides makes it a very productive application development environment, but of what use are they to the end user of the application, say a clerk or a business executive: why should any of the development tools be in the final product? > > It is clear that Slots will be used in the enforcement of typing at the instance variable level, but what about temporary variables? Can a compiler (machine not bytecode) be developed if temporary variables are not typed? Then there is the question of how to handle the elements of heterogeneous collections. > > I have more thoughts, but the above are related to Slots. Any comments? > I donât think that the main power of Slots if typingâ¦ its more slots with behavioural changes or meta data. Slots can be used for providing typed slots, but these would just do a runtime check, slowing down everything. Itâs much more interesting for things like ProperySlots, BooleanSlots (which would be very memory efficient, typing would be just a side effect). For typing, the actually annotations (of ivars, temps, and casting of expressions, return typesâ¦) is not that problemâ¦designing a good type system is the real thing, e.g.: http://rmod.inria.fr/web/publications/bib?query=Alle13a&display=abstract Marcus

June 9, 2014

Slots

by Bob Williams

Camille and Marcus, thank you for your response. I thought something was missing, so the testing of Slots will be shelved for now; however, while it is in the planning stage, I would like to add some thoughts on targets and deliverable products (applications). I agree that most devices like the iPad and iPhone would not be suitable for development, they should be targets for application development and I would expand that list to include all devices, even micro-controllers. Look at the development process for the iPad and iPhone, the programming is done on a Mac using Xcode and testing is done first on the simulator running on the Mac and latter on the actual device. I find the Xcode environment inferior to Smalltalk's and by no stretch of the imagination is Objective-C a good substitute for Smalltalk. I think that development of application programs could be done far better with Smalltalk, provided that some tools were added to Smalltalk. Why not have the view, if it can be programmed in C then it can be programmed in Smalltalk. I think that the application process should be viewed as a series of steps culminating in the production of a product for sale or distribution: develop and test the program logic, test using constraints imposed by the target device, performance testing, test on the target device, and package for sale or distribution. A good examples of the second step where the constraints of the target is imposed are the word size and floating-point precision differences found in the target. If the development of the application is on a 64-bit computer then integer and floating-point calculated must be simulated for targets with smaller word size and for 32-bit floating-point or no floating-point processor. Implicit in those steps is the notion a gradual typing, the first uses the Smalltalk model to generically test the logic of the program, while the final step would require a fully compiled executable for some of the targets. I would argue that one reason that Smalltalk was not a commercial success was that you could not provide a fully compiled executable to the customer. The tools that the Smalltalk environment provides makes it a very productive application development environment, but of what use are they to the end user of the application, say a clerk or a business executive: why should any of the development tools be in the final product? It is clear that Slots will be used in the enforcement of typing at the instance variable level, but what about temporary variables? Can a compiler (machine not bytecode) be developed if temporary variables are not typed? Then there is the question of how to handle the elements of heterogeneous collections. I have more thoughts, but the above are related to Slots. Any comments? bw

June 9, 2014

Re: [Pharo-users] Custom layout in Spec

by Benjamin

On 08 Jun 2014, at 15:21, webwarrior <reg(a)webwarrior.ws> wrote: > I want to make a layout based on TableLayout. Short answer: itâs not really supported yet. If you want to give it a try, itâs really welcome ;) > However, I noticed that SpecInterpreter has some hardcoded behaviour for > ContainerModel in computeSpecFrom:selector: method. Is this behaviour really > important, and if yes, how can I replicate it? Itâs really needed (even thought I do not remember why exactly now (but I think itâs to prevent some infinite loops)). The solution as I was thinking about it would be to have a different keyword per layout. Today, you start your layout with `SpecLayout composed`, where it could be `SpecLayout table`. Or it could be `SpecTableLayout composed`. The main issue you will have is that Spec does not directly rely on Morphic layouts. So you will have to implement some layouting algorithm by yourself. Hope it helps, Ben

June 9, 2014

Re: [Pharo-users] Custom layout in Spec

by Johan Fabry

I have been able to get size respecting behavior using rows and columns, by giving newColumn:width: and newRow:width. Combined with splitters (the addSplitter message) this has worked well for me (modulo some bugs). If you need more complex behavior than that Iâm afraid I cannot help you. On Jun 8, 2014, at 3:39 PM, webwarrior <reg(a)webwarrior.ws> wrote: > My main requirements are such that container respects sizes and resizing > behaviour (hResizing, vResizing) of its child elements. > > Proportional layout doesn't allow that. > > And yes, I've read Spec documentation and some Morphic documentation. > > > > -- > View this message in context: http://forum.world.st/Custom-layout-in-Spec-tp4762142p4762213.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

June 8, 2014