March 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] [TODO 1.4] 12 issues left

by Marcus Denker

Just 12 issues left that are tagged 1.4: http://code.google.com/p/pharo/issues/list?&q=milestone%3D1.4 -> are any of these not show stoppers? -> are there any other tracker entries that are show stoppers for a release? -- Marcus Denker -- http://marcusdenker.de

March 26, 2012

Re: [Pharo-project] File browser with a grid widget

by Alexis Parseghian

>> The current version offers 3 columns : filename, size and modification >> timestamp. Sorting can be on any of them (filename by default). > > That's a very good idea. Thank you. Could you please attach a > screenshot to the issue tracker? Done.

March 26, 2012

Re: [Pharo-project] Cog-Win32 build on Jenkins

by Camillo Bruni

I just updated the jenkins config. best cami On 2012-03-26, at 04:49, Martin Sandiford wrote: > Hi All, > > Any chance that the "Cog-Win32" Jenkins job could be made dependent on > the "Cog Git Tracker (blessed)" job in the same way as the Mac and > Linux VMs are? > > I ask because I see that the job hasn't been built after the last > couple of changes to the blessed repo. > > Cheers, > Martin >

March 26, 2012

Re: [Pharo-project] File browser with a grid widget

by Damien Cassou

On Mon, Mar 26, 2012 at 12:33 AM, Alexis Parseghian <a.parseg(a)gmail.com> wrote: > I've always found the file browser's flat list over filenames a bit > missing, and started experimenting with a grid view. > > The current version offers 3 columns : filename, size and modification > timestamp. Sorting can be on any of them (filename by default). That's a very good idea. Thank you. Could you please attach a screenshot to the issue tracker? Thanks -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

March 26, 2012

[Pharo-project] GSoC more mentors wanted

by Janko MivÅ¡ek

Dear Smalltalkers, We have quite nice projects, but mentors are still missing: http://gsoc2012.esug.org/projects http://gsoc2012.esug.org/mentors Note that current mentors are potential mentors and more project proposers than final mentors, so, if you are interested to mentor some project, contact the current mentor and volunteer to be a mentor, or second mentor, of that project. Same goes for current mentors, please be sure that your projects will have a proper mentor and second mentor. What's difference between mentor and second mentor? Mentor is responsible for a project and student through the whole project lifecycle, while second mentor is officially to replace the main mentor in a case he cannot be mentor for any reasons anymore, but unofficially second mentor also helps the main mentor working on the project. There is only one main and only one second mentor possible. So please, anyone interested please look at the projects and volunteer for membership. By replying to me or Carla, or to the current potential mentors. Best regards Janko -- Janko MivÅ¡ek Smalltalk GSoC Admin Team http://gsoc2012.esug.org

March 26, 2012

Re: [Pharo-project] CogVM speed

by Sven Van Caekenberghe

On 26 Mar 2012, at 09:07, Pavel Krivanek wrote: > I did it on 64bit. However among other things, there is a big issue > with equivalence of the programs. Because the same program in C/C++ > would have to be able to be interrupted any time by an user, contain > debug information to be able to show the computation state in context > of the source codes and modify temporary and instance variables, > enumerate instances of any arbitrary class, serialize current > computation state and continue even on the different platform etc. > That all costs something and in this light the results of Smalltalk > look quite impressive ;-) Well said, Pavel. Sven

March 26, 2012

Re: [Pharo-project] CogVM speed

by Pavel Krivanek

I did it on 64bit. However among other things, there is a big issue with equivalence of the programs. Because the same program in C/C++ would have to be able to be interrupted any time by an user, contain debug information to be able to show the computation state in context of the source codes and modify temporary and instance variables, enumerate instances of any arbitrary class, serialize current computation state and continue even on the different platform etc. That all costs something and in this light the results of Smalltalk look quite impressive ;-) -- Pavel On Mon, Mar 26, 2012 at 8:20 AM, Milan Mimica <milan.mimica(a)gmail.com> wrote: > Have you compared with 32-bit binaries generated by gcc? > > > On 25 March 2012 23:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> >> Hi, >> >> I tried a few benchmarks from Computer Language Benchmark Game >> >> (http://shootout.alioth.debian.org/u32/which-programming-languages-are-faste…) >> on CogVM to compare it with VisualWorks and with the rest of the >> world. >> >> Of course this benchmarks are not ideal (like all benchmarks) but the >> result is that CogVM is in average 1.8 times slower than VisualWorks >> 7.8 NC. For the most successful benchmark (binary-trees) it was 13.5 >> times slower than C (gcc) but in general we may except CogVM to be >> 20-30 times slower than C for this kind of tasks. >> >> Thank you for the great work! >> >> Cheers, >> -- Pavel >> > > > > -- > Milan Mimica > http://sparklet.sf.net

March 26, 2012

Re: [Pharo-project] Seaside Book: Chapter 17, Serving Files

by Philippe Marschall

On 03/26/2012 03:29 AM, Schwab,Wilhelm K wrote: > Stef, > > Thanks for Dynamic Web Development With Seaside - it's a great book! One omission that I have noted is that of dynamically serving files. > > Making a long story short, I have a Seaside app that swallows and regurgitates literature (300 MB and growing). It is what has me interested in Citezen (which is working wonderfully - thanks again!). I wish I had known more about Seaside when I started to write it, but it is slowly improving. Clearly, I can't put hundreds of megabytes in a FileLibrary, and I have no interest in configuring a static web server for something that (sadly or not) runs locally on multiple machines, with data synchronized via what amounts to an rsynch clone and ever-growing flash sticks. It's hard to describe how much better Apache is at serving static files than Seaside/Pharo. The stability, performance, scalability, efficiency, it's from an other world. Cheers Philippe

March 26, 2012

Re: [Pharo-project] Seaside Book: Chapter 17, Serving Files

by Francois Stephany

Yep it works well and if it fits your needs then go for it ;) I serve static assets with Seaside when the files are only accessible for a logged in user or when it depends of the state of the sessions. In other cases, I simply put all my files in a directory next to the image and serve them with Zinc/Kom when I develop On 25/03/12 20:55, Schwab,Wilhelm K wrote: > Francois, > > I am probably missing something too<g>, but dynamically serving the documents is EASY, and that message should get out. The app in question originally ran on a server. At first, that was a way to get around my lack (at the time) of good file synchronizing on Linux - I have long since ported to Pharo a tool that I have use for years so that it runs on Linux. That makes it easy to move files from one machine to another (basically between desktop and laptop). > > Having the system on a server offered the option for others to see the data, but they never used it. IT policies became problematic (or at least scary), and it is simply easier for to run it locally, so I took that plunge. The system has security features that make little sense now; I might remove them some day. > > When it ran on a server, I simply generated urls for the full text articles. At present, serving the files dynamically "just works" and does it w/o the need to think about servers and URLs. It is a nice solution that I think deserves mention along with FileLibrary and other methods. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Francois Stephany [tulipe.moutarde(a)gmail.com] > Sent: Sunday, March 25, 2012 11:23 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Seaside Book: Chapter 17, Serving Files > > Hi Bill, > > I probably miss something in the use case but why don't you simply serve > that static content with Kom or Zinc ? > > > On 25/03/12 18:29, Schwab,Wilhelm K wrote: >> Clearly, I can't put hundreds of megabytes in a FileLibrary, and I have >> no interest in configuring a static web server for something that (sadly >> or not) runs locally on multiple machines, with data synchronized via >> what amounts to an rsynch clone and ever-growing flash sticks. > > -- http://tulipemoutarde.be CA: +1 778 558 3225 BE: +32 65 709 131

March 26, 2012

Re: [Pharo-project] CogVM speed

by Milan Mimica

Have you compared with 32-bit binaries generated by gcc? On 25 March 2012 23:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > I tried a few benchmarks from Computer Language Benchmark Game > ( > http://shootout.alioth.debian.org/u32/which-programming-languages-are-faste… > ) > on CogVM to compare it with VisualWorks and with the rest of the > world. > > Of course this benchmarks are not ideal (like all benchmarks) but the > result is that CogVM is in average 1.8 times slower than VisualWorks > 7.8 NC. For the most successful benchmark (binary-trees) it was 13.5 > times slower than C (gcc) but in general we may except CogVM to be > 20-30 times slower than C for this kind of tasks. > > Thank you for the great work! > > Cheers, > -- Pavel > > -- Milan Mimica http://sparklet.sf.net

March 26, 2012