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

Re: [Pharo-users] Dynamic Typing > Static Typing? Â« games.greggman.com

by Martin BÃ¤hr

Excerpts from Sven Van Caekenberghe's message of 2016-01-19 22:09:44 +0100: > > http://games.greggman.com/game/dynamic-typing-static-typing/ <http://games.greggman.com/game/dynamic-typing-static-typing/> > In a dynamically typed language you write (a lot) less code for a shorter program that is easier and faster to write and debug, which gives you more time to think about what you are doing, resulting in more reliable programs. > > Static typing catches only a (very) small amount of typing errors, that are just as easy to handle as dynamic typing exceptions, but they are a bit faster. if that is the case, then why are people working on typescript, why are both python and ruby getting optional types? i think this is a comparison of apples with oranges. even without typing languages like java, c and c++ are significantly different from dynamic languages like python, ruby, smalltalk and others. adding typing to javascript, python and ruby means that we can have our cake and eat it too. so i'll wait for this study to be redone in the next decade, to compare typed with untyped javascript, python and ruby. and only that will show us the real truth. does adding types, with everything else being equal, really make a difference, or not? btw: the guys at rubyrogues make an interesting argument why lack of typing works better in smalltalk than it does in ruby: http://devchat.cachefly.net/rubyrogues/transcript-155-rr-why-ruby-sucks-rub… read page 8 of that transcript. basically they are saying that because java and c/c++ are compiled they can be analyzed statically and you can build great refactoring tools for them because the tools can predict which methods are the same. and in difference to that smalltalk and lisp only know the code at runtime and so they can't make those predictions. but they make up for that because they are always running. there is no such thing as not runtime. you can simply ask the system about its state, like find out which object in the whole system would respond to a particular message. and in ruby you can't do either of those. disclaimer: for the last 20 years, my main programming language has been pike, a dynamic language like smalltalk, but with declarative typing. (it's optional, in the sense that you can declare a type as "mixed" which can be anything, so just like typescript, and how python and ruby will be once they have optional types) greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

Jan. 20, 2016

[ANN] OSSubprocess v0.2.0 release

by Mariano Martinez Peck

Hi guys, I am happy to announce OSSubprocess v0.2.0. You can see the changelog here: https://github.com/marianopeck/OSSubprocess/releases/tag/v0.2.0 Such version becomes the #stable, so the installation instructions remain the same. Note that I have improved and added more info in the documentation. I took into account most of the feedback I received in the first release plus some other stuff from the survey. If you have more feedback, just let me know! Hope you enjoy. Best, -- Mariano http://marianopeck.wordpress.com

Jan. 20, 2016

Dynamic Typing > Static Typing? Â« games.greggman.com

by Sven Van Caekenberghe

Not that we didn't already know this or that we don't feel like this (else you wouldn't be here), but it is nice to see a concise description and some fact based reasoning around this subject: > http://games.greggman.com/game/dynamic-typing-static-typing/ <http://games.greggman.com/game/dynamic-typing-static-typing/> In summary: In a dynamically typed language you write (a lot) less code for a shorter program that is easier and faster to write and debug, which gives you more time to think about what you are doing, resulting in more reliable programs. Static typing catches only a (very) small amount of typing errors, that are just as easy to handle as dynamic typing exceptions, but they are a bit faster. Sven

Jan. 19, 2016

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

by Damien Cassou

Serge Stinckwich <serge.stinckwich(a)gmail.com> writes: > 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 ? https://github.com/pharo-project/pharo-ci/blob/master/ci-jobs/pharo/Launche… https://github.com/pharo-project/pharo-ci/blob/master/ci-jobs/pharo/Launche… https://github.com/pharo-project/pharo-ci/blob/master/ci-jobs/pharo/Launche… these 3 scripts control the 3 jobs at https://ci.inria.fr/pharo/view/Launcher/ -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Jan. 19, 2016

1st Call for Contributions for SPLASH'16: OOPSLA, Onward!, Workshops, DLS, SLE, GPCE

by Tijs van der Storm

/************************************************************************************/ ACM Conference on Systems, Programming, Languages, and Applications: Software for Humanity (SPLASH'16) Amsterdam, The Netherlands Sun 30th October - Fri 4th November , 2016 http://2016.splashcon.org Sponsored by ACM SIGPLAN /************************************************************************************/ FIRST COMBINED CALL FOR CONTRIBUTIONS: OOPSLA Onward! Workshops Doctoral Symposium Posters Dynamic Languages Symposium (DLS) Software Language Engineering (SLE) Generative Programming: Concepts & Experiences (GPCE) /************************************************************************************/ # SPLASH 2016 The ACM SIGPLAN conference on Systems, Programming, Languages and Applications: Software for Humanity (SPLASH) embraces all aspects of software construction, to make it the premier conference at the intersection of programming, languages, systems, and software engineering. We invite high quality submissions describing original and unpublished work. ## OOPSLA Research Papers Papers that address any aspect of software development are welcome, including requirements, modeling, prototyping, design, implementation, generation, analysis, verification, testing, evaluation, maintenance, reuse, replacement, and retirement of software systems. Papers may address these topics in a variety of ways, including new tools (such as languages, program analyses, and runtime systems), new techniques (such as methodologies, design processes, code organization approaches, and management techniques), and new evaluations (such as formalisms and proofs, corpora analyses, user studies, and surveys). Submissions due: Wed 23 March, 2016 http://2016.splashcon.org/track/splash-2016-oopsla ## Onward! Research Papers Onward! is a premier multidisciplinary conference focused on everything to do with programming and software: including processes, methods, languages, communities, and applications. Onward! is more radical, more visionary, and more open than other conferences to ideas that are well-argued but not yet proven. We welcome different ways of thinking about, approaching, and reporting on programming language and software engineering research. Submissions due: Fri 1 April, 2016 http://2016.splashcon.org/track/onward2016/onward-2016-papers ## Onward! Essays Onward! Essays is looking for clear and compelling pieces of writing about topics important to the software community. An essay can be an exploration of a topic, its impact, or the circumstances of its creation; it can present a personal view of what is, explore a terrain, or lead the reader in an act of discovery; it can be a philosophical digression or a deep analysis. It can describe a personal journey, perhaps by which the author reached an understanding of such a topic. The subject area should be interpreted broadly and can include the relationship of software to human endeavors, or its philosophical, sociological, psychological, historical, or anthropological underpinnings. Submissions due: Fri 1 April, 2016 http://2016.splashcon.org/track/onward2016/onward2016-essays ## Workshops The SPLASH Workshops track will host a variety of high-quality workshops, allowing their participants to meet and discuss research questions with peers, to mature new and exciting ideas, and to build up communities and start new collaborations. SPLASH workshops complement the main tracks of the conference and provide meetings in a smaller and more specialized setting. Workshops cultivate new ideas and concepts for the future, optionally recorded in formal proceedings. Late Phase Submissions of Workshop Proposals due: Fri 4 Mar, 2016 http://2016.splashcon.org/track/splash2016-workshops ## Doctoral Symposium The SPLASH Doctoral Symposium provides students with useful guidance for completing their dissertation research and beginning their research careers. The Symposium will provide an interactive forum for doctoral students who have progressed far enough in their research to have a structured proposal, but will not be defending their dissertation in the next 12 months. Submissions due: Thu 30 Jun, 2016 http://2016.splashcon.org/track/splash-2016-ds ## Posters The SPLASH Poster track provides an excellent forum for authors to present their recent or ongoing projects in an interactive setting, and receive feedback from the community. We invite submissions covering any aspect of programming, systems, languages and applications. The goal of the poster session is to encourage and facilitate small groups of individuals interested in a technical area to gather and interact. Poster submissions due: Fri 8 Jul, 2016 http://2016.splashcon.org/track/splash-2016-posters ## Dynamic Languages Symposium (DLS) DLS is the premier forum for researchers and practitioners to share knowledge and research on dynamic languages, their implementation, and applications. The influence of dynamic languages â from Lisp to Smalltalk to Python to Javascript â on real-world practice, and research, continues to grow. We invite high quality papers reporting original research, innovative contributions, or experience related to dynamic languages, their implementation, and applications. Submissions due: Fri 10 June, 2016 http://2016.splashcon.org/track/dls-2016/dls-2016-papers ## Software Language Engineering (SLE) Software Language Engineering (SLE) is the application of systematic, disciplined, and measurable approaches to the development, use, deployment, and maintenance of software languages. The term âsoftware languageâ is used broadly, and includes: general-purpose programming languages; domain-specific languages (e.g. BPMN, Simulink, Modelica); modeling and metamodeling languages (e.g. SysML and UML); data models and ontologies (e.g. XML-based and OWL-based languages and vocabularies). SLE solicits high-quality contributions in areas ranging from theoretical and conceptual contributions to tools, techniques, and frameworks in the domain of language engineering. Submissions due: Fri 17 June, 2016 (abstracts); Fri 24 June, 2016 (papers) http://2016.splashcon.org/track/sle-2016/sle-2016-papers ## Generative Programming: Concepts & Experiences (GPCE) The International Conference on Generative Programming: Concepts & Experiences (GPCE) is a venue for researchers and practitioners interested in techniques that use program generation, domain-specific languages, and component deployment to increase programmer productivity, improve software quality, and shorten the time-to-market of software products. In addition to exploring cutting-edge techniques of generative software, our goal is to foster further cross-fertilization between the software engineering and the programming languages research communities. Submissions due: Fri 17 June, 2016 (abstracts); Fri 24 June, 2016 (papers) http://2016.splashcon.org/track/gpce-2016/gpce-2016-papers ## Information Contact: publicity(a)splashcon.org Website: http://2016.splashcon.org Location: MÃ¶venpick Hotel Amsterdam City Centre Amsterdam, The Netherlands ## Organization: SPLASH General Chair: Eelco Visser (TU Delft) OOPSLA Papers Chair: Yannis Smaragdakis (University of Athens) Onward! Papers Chair: Emerson Murphy-Hill (North Carolina State University) Onward! Essays Chair: Crista Lopes (University of California, Irvine) DLS PC Chair: Roberto Ierusalimschy (PUC-Rio) SLE PC Co-Chairs: Emilie Balland (Sensational AG) and Daniel Varro (Budapest University of Technology and Economics) GPCE PC Chair: Ina Schaefer (TU Braunschweig) Doctoral Symposium Chair: Matthew Flatt (University of Utah) SPLASH-E Co-Chair: Matthias Hauswirth (University of Lugano) and Steve Blackburn (Australian National University) SPLASH-I Co-Chairs: Eelco Visser (TU Delft) and Tijs van der Storm (CWI) Artifacts Co-Chairs: Michael Hind (IBM Research) and Michael Bond (Ohio State University) Workshops Co-Chairs: Jan Rellermeyer (IBM Research) and Craig Anslow (Middlesex University, London) Posters Co-Chairs: Sebastian Erdweg (TU Darmstadt) and Jeff Huang (Texas A&M University) Student Research Competition Co-Chairs: Patrick Lam (University of Waterloo) and Sam Guyer (Tufts University) Student Volunteer Co-Chairs: Daco Harkes (TU Delft) and Giovanni Viviani (University of British Columbia) Publications Chair: Alex Potanin (Victoria University of Wellington) Sponsorship Chair: Jurgen Vinju (Purdue University) Publicity and Web Co-Chairs: Tijs van der Storm (CWI) and Ron Garcia (University of British Columbia) Web Technology Chair: Eelco Visser (TU Delft) /************************************************************************************/ -- Researcher Centrum Wiskunde & Informatica (CWI) Master of Software Engineering Universiteit van Amsterdam (UvA) Dr. Tijs van der Storm @ Centrum Wiskunde & Informatica (CWI) Office: L225 | Phone: +31 (0)20 5924164 | Address: Science Park 123 P.O. Box 94079 | Postal code: 1090 GB | Amsterdam, The Netherlands

Jan. 19, 2016

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

by Dimitris Chloupis

thanks ben that indeed get the cairo 32 bit version but there must be a version mismatch because now pharo complains "Error:Could not find accessor for variable named "aCairoSurfaceHandle" " On Tue, Jan 19, 2016 at 3:30 PM Ben Coman <btc(a)openinworld.com> wrote: > $ apt-cache search cairo | grep cairo | less > shows... libcairo2 - Cairo 2D vector graphics library > > so following the pattern for Debian here... > http://pharo.org/gnu-linux-installation > > I presume... > $ sudo dpkg --add-architecture i386 > $ sudo apt-get update > $ sudo apt-get install libcairo2:i386 > > ...but haven't tried this since I'm using 32-bit Debian. > > cheers -ben > > On Tue, Jan 19, 2016 at 9:02 PM, Dimitris Chloupis > <kilon.alios(a)gmail.com> wrote: > > ah yes it needs the 32 bit libs of cairo, yeah good luck with that, cant > > wait till we finally support 64 bit, but far my most needed feature of > > pharo. No idea how to find 32 bit lib of cairo, google returns nothing > > meaningful, download page of cairo website mentions nothing. > > > > On Tue, Jan 19, 2016 at 2:52 PM Dimitris Chloupis <kilon.alios(a)gmail.com > > > > wrote: > >> > >> does not work for me on ubuntu it keeps saying that "cannot locate cairo > >> library" even though its installed via > >> > >> sudo apt-get install libcairo2-dev > >> > >> By the way just for the fun, I will make a benchmark comparison betweem > >> PNG loader in pharo and SDL in C to see what is the speed difference and > >> dust off my C skills. > >> > >> On Tue, Jan 19, 2016 at 2:22 PM Esteban Lorenzano <estebanlm(a)gmail.com> > >> wrote: > >>> > >>> Yesterday I tested creating PNGs from disk using Athens: > >>> > >>> [(AthensCairoSurface > >>> createFromFile: '/Users/esteban/Dev/Pharo/pharo50/Lenna.png' > >>> ifFailed: [ ]) > >>> asForm] bench. > >>> > >>> That gave me 46k/s â¦ (455k image) which IMO is pretty reasonable :) > >>> > >>> Esteban > >>> > >>> > On 19 Jan 2016, at 12:34, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>> > > >>> > > >>> >> On 19 Jan 2016, at 12:29, PBKResearch <peter(a)pbkresearch.co.uk> > wrote: > >>> >> > >>> >> Denis > >>> >> > >>> >> Very interesting. It would be more interesting if you could save > your > >>> >> test image as a .png file, and then include reading with > PNGReadWriter in > >>> >> your comparison. This would help to confirm or refute the original > point > >>> >> made by Dimitris, that reading from .png is particularly slow. > >>> > > >>> > Check the original thread/case, it is slow. Not *very* slow, but > slower > >>> > than the plugin based JPEG reader. That is what we eventually need, > a plugin > >>> > base PNG reader. > >>> > > >>> >> Peter Kenny > >>> >> > >>> >> From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On > >>> >> Behalf Of Denis Kudriashov > >>> >> Sent: 19 January 2016 10:59 > >>> >> To: Any question about pharo is welcome < > pharo-users(a)lists.pharo.org> > >>> >> Subject: Re: [Pharo-users] Creation form from PNG file very slow on > >>> >> Pharo 4 and 5 > >>> >> > >>> >> > >>> >> 2016-01-19 11:34 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com > >: > >>> >>> most likely fuel, since it stores your live object as is. > >>> >>> > >>> >>> I like fuel but the fact that I may be limited by incompatible > >>> >>> versions is a game stopper for me. I am ok with new version between > >>> >>> incompatible with old one but there must be some backward > compatibility to > >>> >>> any format I use. Or else I end up worrying about things I should > not be > >>> >>> worrying about. > >>> >> > >>> >> You are right. I perform little experiment. Fuel reading is 60% > faster > >>> >> than BMP: > >>> >> > >>> >> Smalltalk garbageCollect; garbageCollect. > >>> >> r1 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s | > >>> >> s binary. > >>> >> fromBMP := BMPReadWriter formFromStream: s]] benchFor: 2 seconds. > >>> >> > >>> >> Smalltalk garbageCollect; garbageCollect. > >>> >> r2:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s | > >>> >> s binary. > >>> >> fromFuel := (FLMaterializer newDefault materializeFrom: s) root]] > >>> >> benchFor: 2 seconds. > >>> >> > >>> >> { r1. r2 } "an Array(a BenchmarkResult(2,199 iterations in 2 > seconds 2 > >>> >> milliseconds. 1,098 per second) a BenchmarkResult(5,728 iterations > in 2 > >>> >> seconds 3 milliseconds. 2,860 per second))" > >>> > > >>> > > >>> > >>> > > > >

Jan. 19, 2016

spotter: top search for senders and references

by Tudor Girba

Hi, With the latest GT integration, we also integrated the search for senders and references from the first step. Here is a detailed explanation about it, including what we still want to do, how itâs done, and how to discover what else is around: http://www.humane-assessment.com/blog/spotting-senders-references-with-gtsp… Please let us know what you think. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."

Jan. 19, 2016

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

by Ben Coman

$ apt-cache search cairo | grep cairo | less shows... libcairo2 - Cairo 2D vector graphics library so following the pattern for Debian here... http://pharo.org/gnu-linux-installation I presume... $ sudo dpkg --add-architecture i386 $ sudo apt-get update $ sudo apt-get install libcairo2:i386 ...but haven't tried this since I'm using 32-bit Debian. cheers -ben On Tue, Jan 19, 2016 at 9:02 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > ah yes it needs the 32 bit libs of cairo, yeah good luck with that, cant > wait till we finally support 64 bit, but far my most needed feature of > pharo. No idea how to find 32 bit lib of cairo, google returns nothing > meaningful, download page of cairo website mentions nothing. > > On Tue, Jan 19, 2016 at 2:52 PM Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: >> >> does not work for me on ubuntu it keeps saying that "cannot locate cairo >> library" even though its installed via >> >> sudo apt-get install libcairo2-dev >> >> By the way just for the fun, I will make a benchmark comparison betweem >> PNG loader in pharo and SDL in C to see what is the speed difference and >> dust off my C skills. >> >> On Tue, Jan 19, 2016 at 2:22 PM Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >>> >>> Yesterday I tested creating PNGs from disk using Athens: >>> >>> [(AthensCairoSurface >>> createFromFile: '/Users/esteban/Dev/Pharo/pharo50/Lenna.png' >>> ifFailed: [ ]) >>> asForm] bench. >>> >>> That gave me 46k/s â¦ (455k image) which IMO is pretty reasonable :) >>> >>> Esteban >>> >>> > On 19 Jan 2016, at 12:34, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> > >>> > >>> >> On 19 Jan 2016, at 12:29, PBKResearch <peter(a)pbkresearch.co.uk> wrote: >>> >> >>> >> Denis >>> >> >>> >> Very interesting. It would be more interesting if you could save your >>> >> test image as a .png file, and then include reading with PNGReadWriter in >>> >> your comparison. This would help to confirm or refute the original point >>> >> made by Dimitris, that reading from .png is particularly slow. >>> > >>> > Check the original thread/case, it is slow. Not *very* slow, but slower >>> > than the plugin based JPEG reader. That is what we eventually need, a plugin >>> > base PNG reader. >>> > >>> >> Peter Kenny >>> >> >>> >> From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On >>> >> Behalf Of Denis Kudriashov >>> >> Sent: 19 January 2016 10:59 >>> >> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>> >> Subject: Re: [Pharo-users] Creation form from PNG file very slow on >>> >> Pharo 4 and 5 >>> >> >>> >> >>> >> 2016-01-19 11:34 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >>> >>> most likely fuel, since it stores your live object as is. >>> >>> >>> >>> I like fuel but the fact that I may be limited by incompatible >>> >>> versions is a game stopper for me. I am ok with new version between >>> >>> incompatible with old one but there must be some backward compatibility to >>> >>> any format I use. Or else I end up worrying about things I should not be >>> >>> worrying about. >>> >> >>> >> You are right. I perform little experiment. Fuel reading is 60% faster >>> >> than BMP: >>> >> >>> >> Smalltalk garbageCollect; garbageCollect. >>> >> r1 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s | >>> >> s binary. >>> >> fromBMP := BMPReadWriter formFromStream: s]] benchFor: 2 seconds. >>> >> >>> >> Smalltalk garbageCollect; garbageCollect. >>> >> r2:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s | >>> >> s binary. >>> >> fromFuel := (FLMaterializer newDefault materializeFrom: s) root]] >>> >> benchFor: 2 seconds. >>> >> >>> >> { r1. r2 } "an Array(a BenchmarkResult(2,199 iterations in 2 seconds 2 >>> >> milliseconds. 1,098 per second) a BenchmarkResult(5,728 iterations in 2 >>> >> seconds 3 milliseconds. 2,860 per second))" >>> > >>> > >>> >>> >

Jan. 19, 2016

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

by Dimitris Chloupis

ah yes it needs the 32 bit libs of cairo, yeah good luck with that, cant wait till we finally support 64 bit, but far my most needed feature of pharo. No idea how to find 32 bit lib of cairo, google returns nothing meaningful, download page of cairo website mentions nothing. On Tue, Jan 19, 2016 at 2:52 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > does not work for me on ubuntu it keeps saying that "cannot locate cairo > library" even though its installed via > > sudo apt-get install libcairo2-dev > > By the way just for the fun, I will make a benchmark comparison betweem > PNG loader in pharo and SDL in C to see what is the speed difference and > dust off my C skills. > > On Tue, Jan 19, 2016 at 2:22 PM Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> Yesterday I tested creating PNGs from disk using Athens: >> >> [(AthensCairoSurface >> createFromFile: '/Users/esteban/Dev/Pharo/pharo50/Lenna.png' >> ifFailed: [ ]) >> asForm] bench. >> >> That gave me 46k/s â¦ (455k image) which IMO is pretty reasonable :) >> >> Esteban >> >> > On 19 Jan 2016, at 12:34, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> > >> > >> >> On 19 Jan 2016, at 12:29, PBKResearch <peter(a)pbkresearch.co.uk> wrote: >> >> >> >> Denis >> >> >> >> Very interesting. It would be more interesting if you could save your >> test image as a .png file, and then include reading with PNGReadWriter in >> your comparison. This would help to confirm or refute the original point >> made by Dimitris, that reading from .png is particularly slow. >> > >> > Check the original thread/case, it is slow. Not *very* slow, but slower >> than the plugin based JPEG reader. That is what we eventually need, a >> plugin base PNG reader. >> > >> >> Peter Kenny >> >> >> >> From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On >> Behalf Of Denis Kudriashov >> >> Sent: 19 January 2016 10:59 >> >> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >> >> Subject: Re: [Pharo-users] Creation form from PNG file very slow on >> Pharo 4 and 5 >> >> >> >> >> >> 2016-01-19 11:34 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >> >>> most likely fuel, since it stores your live object as is. >> >>> >> >>> I like fuel but the fact that I may be limited by incompatible >> versions is a game stopper for me. I am ok with new version between >> incompatible with old one but there must be some backward compatibility to >> any format I use. Or else I end up worrying about things I should not be >> worrying about. >> >> >> >> You are right. I perform little experiment. Fuel reading is 60% faster >> than BMP: >> >> >> >> Smalltalk garbageCollect; garbageCollect. >> >> r1 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s | >> >> s binary. >> >> fromBMP := BMPReadWriter formFromStream: s]] benchFor: 2 seconds. >> >> >> >> Smalltalk garbageCollect; garbageCollect. >> >> r2:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s | >> >> s binary. >> >> fromFuel := (FLMaterializer newDefault materializeFrom: s) root]] >> benchFor: 2 seconds. >> >> >> >> { r1. r2 } "an Array(a BenchmarkResult(2,199 iterations in 2 seconds 2 >> milliseconds. 1,098 per second) a BenchmarkResult(5,728 iterations in 2 >> seconds 3 milliseconds. 2,860 per second))" >> > >> > >> >> >>

Jan. 19, 2016

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

by Dimitris Chloupis

does not work for me on ubuntu it keeps saying that "cannot locate cairo library" even though its installed via sudo apt-get install libcairo2-dev By the way just for the fun, I will make a benchmark comparison betweem PNG loader in pharo and SDL in C to see what is the speed difference and dust off my C skills. On Tue, Jan 19, 2016 at 2:22 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Yesterday I tested creating PNGs from disk using Athens: > > [(AthensCairoSurface > createFromFile: '/Users/esteban/Dev/Pharo/pharo50/Lenna.png' > ifFailed: [ ]) > asForm] bench. > > That gave me 46k/s â¦ (455k image) which IMO is pretty reasonable :) > > Esteban > > > On 19 Jan 2016, at 12:34, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > >> On 19 Jan 2016, at 12:29, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > >> > >> Denis > >> > >> Very interesting. It would be more interesting if you could save your > test image as a .png file, and then include reading with PNGReadWriter in > your comparison. This would help to confirm or refute the original point > made by Dimitris, that reading from .png is particularly slow. > > > > Check the original thread/case, it is slow. Not *very* slow, but slower > than the plugin based JPEG reader. That is what we eventually need, a > plugin base PNG reader. > > > >> Peter Kenny > >> > >> From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On > Behalf Of Denis Kudriashov > >> Sent: 19 January 2016 10:59 > >> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > >> Subject: Re: [Pharo-users] Creation form from PNG file very slow on > Pharo 4 and 5 > >> > >> > >> 2016-01-19 11:34 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > >>> most likely fuel, since it stores your live object as is. > >>> > >>> I like fuel but the fact that I may be limited by incompatible > versions is a game stopper for me. I am ok with new version between > incompatible with old one but there must be some backward compatibility to > any format I use. Or else I end up worrying about things I should not be > worrying about. > >> > >> You are right. I perform little experiment. Fuel reading is 60% faster > than BMP: > >> > >> Smalltalk garbageCollect; garbageCollect. > >> r1 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s | > >> s binary. > >> fromBMP := BMPReadWriter formFromStream: s]] benchFor: 2 seconds. > >> > >> Smalltalk garbageCollect; garbageCollect. > >> r2:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s | > >> s binary. > >> fromFuel := (FLMaterializer newDefault materializeFrom: s) root]] > benchFor: 2 seconds. > >> > >> { r1. r2 } "an Array(a BenchmarkResult(2,199 iterations in 2 seconds 2 > milliseconds. 1,098 per second) a BenchmarkResult(5,728 iterations in 2 > seconds 3 milliseconds. 2,860 per second))" > > > > > > >

Jan. 19, 2016