January 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Generating a binary package like PharoLauncher

by Esteban A. Maringolo

If it exists, please check the windows installer of Pharo-Launcher, it complains about an integrity check failure. :) If you can access the scrips, this is the CI for it: https://ci.inria.fr/pharo/view/Launcher/job/Launcher/ Regards! Esteban A. Maringolo 2016-01-18 14:23 GMT-03:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > Dear all, > > I would like to distribute Kendrick like PharoLauncher, i.e as a > binary package for mac and windows. Are the script of CI for > generating PharoLauncher available somewhere ? > > Thank you. > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ >

Jan. 18, 2016

Generating a binary package like PharoLauncher

by Serge Stinckwich

Dear all, I would like to distribute Kendrick like PharoLauncher, i.e as a binary package for mac and windows. Are the script of CI for generating PharoLauncher available somewhere ? Thank you. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Jan. 18, 2016

Re: [Pharo-users] Updated Pharo by Example

by Johan Fabry

I may be old-fashioned, but I think that there is nothing wrong with using mailman for a list for developers. > On Jan 18, 2016, at 13:24, Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> wrote: > > > > On 18/01/16 03:59, David Allouche wrote: >> Send an email to pharo-users-request(a)lists.pharo.org <mailto:pharo-users-request@lists.pharo.org> with subject "unsubscribe" from the subscribed address. >> >> mailto:pharo-users-request@lists.pharo.org?subject=unsubscribe <mailto:pharo-users-request@lists.pharo.org?subject=unsubscribe> >> >> To all: it would be nice to switch away from Mailman to something mere mortals can use. It's not 2000 any more. >> >> > > But please... let's not make it google groups. The way google hides you can subscribe *without* having a Google account seems to "business and data cropping oriented" to say the least. > > Cheers, > > Offray ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Jan. 18, 2016

Re: [Pharo-users] Updated Pharo by Example

by Offray Vladimir Luna CÃ¡rdenas

On 18/01/16 03:59, David Allouche wrote: > Send an email to pharo-users-request(a)lists.pharo.org > <mailto:pharo-users-request@lists.pharo.org> with subject > "unsubscribe" from the subscribed address. > > mailto:pharo-users-request@lists.pharo.org?subject=unsubscribe > > To all: it would be nice to switch away from Mailman to something mere > mortals can use. It's not 2000 any more. > > But please... let's not make it google groups. The way google hides you can subscribe *without* having a Google account seems to "business and data cropping oriented" to say the least. Cheers, Offray

Jan. 18, 2016

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

by Esteban A. Maringolo

If you use that many images and require all of them at once, maybe spriting them is an option. That's the first recommendation using a gaming-based approach. Regards, Esteban A. Maringolo 2016-01-18 11:27 GMT-03:00 Hilaire <hilaire(a)drgeo.eu>: > Fuel is very easy to use and pretty fast. Sadly from one image to > another you have to migrate your fuel data. > > An alternative will be to use an Sqlite database, it comes with a bonus: > the format is stable. No idea about speed however. > > Hilaire > > > > Le 17/01/2016 19:58, Stephan Eggermont a Ã©crit : >> Put the forms in one fuel file and materialize that > > -- > Dr. Geo > http://drgeo.eu > >

Jan. 18, 2016

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

by Hilaire

Fuel is very easy to use and pretty fast. Sadly from one image to another you have to migrate your fuel data. An alternative will be to use an Sqlite database, it comes with a bonus: the format is stable. No idea about speed however. Hilaire Le 17/01/2016 19:58, Stephan Eggermont a Ã©crit : > Put the forms in one fuel file and materialize that -- Dr. Geo http://drgeo.eu

Jan. 18, 2016

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

by Dimitris Chloupis

I am not convinced, the problem is that 80% of my slow down is on the pharo side , the primitive takes 200ms to read the file, 900-1000 ms are taken to convert to Form so I dont see how making sprites will help me much. I know you want to blame the hardware , but this is clearly a pharo issue. I have already posted the my profiling results. Since half of form creation is the seconds indicator I can stream it so it loads one png per second which should make the opening of gui much faster. I will find a way , its not a big deal. This thread was never about a problem I cant solve , but rather a notice that there is a part of pharo that is highly inefficient. On Mon, Jan 18, 2016 at 12:12 PM Stephan Eggermont <stephan(a)stack.nl> wrote: > On 18-01-16 10:27, Thierry Goubier wrote: > > Hi Kilon, > > > > Le 17/01/2016 22:25, Dimitris Chloupis a Ã©crit : > >> Fuel is great indeed and very convenient ,will definetly use this > >> approach if I end up dealing with a lot of PNGs and experience some > >> serious delays, but for now, lazy loading with some forking should be > >> enough to make this instantaneous . I prefer to stick with pngs because > >> it easy to update them and version control them via git and github > > > > I think there is a way to cache your pngs, their creation time, and load > > them only once upon installation of your tool, and update them in memory > > only if they have been changed on disk. > > > > I suspect all media heavy software have tactics to work around the same > > performance issues: multi-resource formats (zip or fuel) and the same > > kind of caching (load only once when installing the software). > > Yes, and combining multiple resources in one file to increase the > likelihood that they will be on the same track of a disk instead of on > 60 different ones. In web software there is the same problem with > multiple images. The browser doesn't give you many threads to download > them in parallel. If you only get two and have to download 60 images > from the other side of the ocean... > https://css-tricks.com/css-sprites/ > > Stephan > > >

Jan. 18, 2016

Re: [Pharo-users] Memory mapped files and Pharo (aka Unreal Engine 4 integration with Pharo)

by Dimitris Chloupis

the way I see it at least, polling is not a problem, Graphics work on frame loop, that means actions that have to repeat per frame , Unreal objects are constructed around this functionality , same way we have a World cycle that drawOn: methods work , then of course you have event loops etc. A signal mechanism would have been a callback functionality but frankly I dont think its necessary. My goal is to bring unreal closer to pharo , so that means I will use similar functionality to Morphic and Bloc for drawing to make easy for pharo guis to port to unreal because unreal is not only capable of 3d but also 2d graphics. So the idea is when the frame loops starts , execute first what Unreal has to execute , then read a message qeue where pharo will register messages very similar to pharo messaging . I may allow Pharo to assign messages to specific frames. Those messages will call functions/methods of the Unreal API. Of course it can work vice versa so that Unreal becomes aware of the Pharo enviroment and callback pharo mehods etc and even Blender methods (for asset creation) and I could even hook on this message que many other applications essential to build a common language that apps and libraries can talk to each other without depending on specific implementation and wrapper APIs. Thats the general idea , so far, open to redesign and rethinking depending on the obstacles I may face. On Mon, Jan 18, 2016 at 10:14 AM David Allouche <david(a)allouche.net> wrote: > > > On 17 Jan 2016, at 22:18, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > Pipes are actually slower than sockets (local UNIX sockets that is) and > I dont need sockets if I am using shared memory. > > > > I could create an event que and not allow direct access to shared > memory, this way I make sure everything happens in order and in sequence. > This way I can make sure multiple writes and reads dont happen at the same > time. This could be a first implementation and if the need arises for multi > threading then I can revise this design but frankly I rather stay away from > multithreading and other complexities and keep this simple and easy to > learn and code. > > You will still need a signalling channel so either side knows that it has > new commands to process without having to poll. > > >

Jan. 18, 2016

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

by Stephan Eggermont

On 18-01-16 10:27, Thierry Goubier wrote: > Hi Kilon, > > Le 17/01/2016 22:25, Dimitris Chloupis a Ã©crit : >> Fuel is great indeed and very convenient ,will definetly use this >> approach if I end up dealing with a lot of PNGs and experience some >> serious delays, but for now, lazy loading with some forking should be >> enough to make this instantaneous . I prefer to stick with pngs because >> it easy to update them and version control them via git and github > > I think there is a way to cache your pngs, their creation time, and load > them only once upon installation of your tool, and update them in memory > only if they have been changed on disk. > > I suspect all media heavy software have tactics to work around the same > performance issues: multi-resource formats (zip or fuel) and the same > kind of caching (load only once when installing the software). Yes, and combining multiple resources in one file to increase the likelihood that they will be on the same track of a disk instead of on 60 different ones. In web software there is the same problem with multiple images. The browser doesn't give you many threads to download them in parallel. If you only get two and have to download 60 images from the other side of the ocean... https://css-tricks.com/css-sprites/ Stephan

Jan. 18, 2016

Re: [Pharo-users] Creation form from PNG file very slow on Pharo 4 and 5

by Thierry Goubier

Hi Kilon, Le 17/01/2016 22:25, Dimitris Chloupis a Ã©crit : > Fuel is great indeed and very convenient ,will definetly use this > approach if I end up dealing with a lot of PNGs and experience some > serious delays, but for now, lazy loading with some forking should be > enough to make this instantaneous . I prefer to stick with pngs because > it easy to update them and version control them via git and github I think there is a way to cache your pngs, their creation time, and load them only once upon installation of your tool, and update them in memory only if they have been changed on disk. I suspect all media heavy software have tactics to work around the same performance issues: multi-resource formats (zip or fuel) and the same kind of caching (load only once when installing the software). Thierry > On Sun, Jan 17, 2016 at 11:18 PM Mariano Martinez Peck > <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > > Fuel all the way down :) > > On Sun, Jan 17, 2016 at 5:17 PM, Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>> wrote: > > Hi, > > > On Jan 17, 2016, at 8:27 PM, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > > > > > >> On 17 Jan 2016, at 19:58, Stephan Eggermont <stephan(a)stack.nl <mailto:stephan@stack.nl>> wrote: > >> > >> On 16-01-16 13:50, Dimitris Chloupis wrote: > >>> Seems that creating forms and morph from pngs is super slow > >> > >> Put the forms in one fuel file and materialize that > >> > >> Stephan > > > > That is exactly what I showed him inhttps://pharo.fogbugz.com/f/cases/17403/Creating-Forms-from-PNGs-is-very-… > > That is actually a very cool idea. Thank you both :) > > Doru > > > The speedup was massive and it was so easy to do. > > > > But the fact remains that the PNG parser itself, being written in pure Pharo, could use a Plugin counterpart, like in the JPG case. > > > > Sven > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > www.feenk.com <http://www.feenk.com> > > "Sometimes the best solution is not the best solution." > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 18, 2016