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

Re: [Pharo-project] pdf4smalltalk Re: pharo vision

by S Krish

Additionally why not look at using XMLRPC bridge to do Jasper Reports.. or even CrystalReports.. Of course this will require little bit of backend work on a Groovy / Ruby/ Python or Webservice link to JasperServer.. if its commercial.. or Ruby for its fairly workable pdf writer.. Great though to have a fully functional pdf writer in Smalltalk/ Pharo. On 2/1/12, Ben Coman <btc(a)openinworld.com> wrote: > It took some hunting but I finally found the source located here... > http://pdf4smalltalk.origo.ethz.ch/wiki/store_access > > with MIT License specified here... > http://pdf4smalltalk.origo.ethz.ch/ > > That looks quite promising. > > cheers, Ben > > > StÃ©phane Ducasse wrote: >> On Jan 31, 2012, at 5:13 PM, Ben Coman wrote: >> >> >>> Stef, >>> >>> I've sent some markup directly, some additional ideas - perhaps only for >>> later and/or more of a library than core functionality. >>> >>> Improved printing subsystem - by which I mean PDF output. >>> Business proposition: Without good PDFs many contemporary business >>> practices are curtailed. For example, multi-page reporting charts being >>> emailed to external clients. >>> >> >> Are you aware of the open-source library of Christian Haider? >> >> >>> Running multiple images on one VM with copy-on-write shared memory. >>> Business proposition: To allow more images (owned by different clients) >>> to be run (presumably) with less resources on resource limited web server >>> platforms. >>> > > >

Feb. 1, 2012

Re: [Pharo-project] Smalltalk for small projects only?

by Igor Stasenko

On 29 January 2012 18:48, Philippe Marschall <kustos(a)gmx.net> wrote: > On 29.01.2012 17:02, Sven Van Caekenberghe wrote: >> >> >> On 29 Jan 2012, at 15:30, Philippe Marschall wrote: >> >>>> As for scale.. monticello scales well. >>> >>> >>> No, it does not. >> >> >> Please elaborate: I really can't see the difference between doing a merge >> (either an easy one or a more diffucult one over multiple files, spread over >> a couple of days, with intervening changes by others) using either >> Monticello or Git. > > > The scalability limits of Monticello are well understood. PackageInfo > doesn't scale, at all. You put too many classes in a package, and > snapshotting gets really slow. Don't believe me? Make a change in Morphic > which has only 200 classes and save it. so don't make too many classes in one package. > > And it's not like loading is any faster. Seaside takes 10 minutes to build > from locally cached [1] packages, only 12 seconds go to running tests [2]. > This makes C++ compilation times seem fast by comparison. > Bah.. read this http://marianopeck.wordpress.com/2011/09/24/importing-and-exporting-package… Soâ¦. if you have followed the previous steps, then just open âFuel.imageâ (a new Pharo 1.3 image where Fuel is loaded but seaside is not), paste the previous code into a workspace and execute it. Of course that it depends on the machine, but here (Mac Book Pro i5), it only takes 10 seconds. And we can store packages serialized by Fuel. Actually we're not speaking about scale in same sense. It is not about package size or time they load (i can always put an infinite loop in one of #initialize methods of my class, so it will take an infinite time to load a package with it ;) , but putting a bunch of developers to work on a single project. MC has some deficiencies, but not in that regard. > Â [1] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/buildTimeTrend > Â [2] > http://jenkins.lukas-renggli.ch/job/Seaside%203.1/lastCompletedBuild/testRe… > > Cheers > Philippe > > -- Best regards, Igor Stasenko.

Feb. 1, 2012

Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?

by Igor Stasenko

On 1 February 2012 16:12, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 1 February 2012 14:44, Damien Pollet <damien.pollet(a)gmail.com> wrote: >> On 31 January 2012 15:59, Otto Behrens <otto(a)finworks.biz> wrote: >>> I was wondering more if it is possible to do without having a file >>> system checkout of the class definition. In other words, if the class >>> definition in the image could serve as the working copy of the object >>> in the git repository. I must read more on what the other guys did >>> with the git interfaces (such as gitfs and gitosis) to understand what >>> it comes down to. >>> >>> If this is possible, it would make merging, loading and committing >>> essentially one step. >> >> Have you seen what Camillo did? >> http://www.squeaksource.com/FSGit >> https://github.com/dh83/fs-git-test >> >> Note the layout with class comment in a README file, etc :) > > That is _exactly_ the right thing to do! Bravo, Camillo! Also note how > Nested-Package-Names end up looking like you might expect. > > Is there any necessity for storing a chunk? For instance in > https://github.com/dh83/fs-git-test/blob/master/AAA/AAA.class/instance-side… > we have > > !AAA methodsFor: 'as yet unclassified' stamp: 'CamilloBruni 1/23/2012 19:15'! > a > Â Â Â Â | a | > Â Â Â Â ^ a! ! > > with the ugly chunk !s. The only thing we can't directly regenerate is > the timestamp: modulo that, we know the class name, the category (the > name of the directory you're in), the author (from the author of the > git commit). You'd have a disconnect between the git commit time and > the time in the chunk which would, IIRC, be the time you hit Alt-S in > your browser? Or would that be file-out time, which would likely then > be the timestamp in the git commit? > Good question, Frank. But i want to go even further by saying: why we cannot associate an arbitrary meta-information per method and store it along with method? Today we storing the category, author and stamp. Tomorrow we may want to add something more (link to documentation, link to previous version etc etc) And i think , at least in GitFS Camillo can do it pretty easy. If you have 1 file per method, make 2 files per method, i.e.: methodname.st methodname.meta and in meta, we can store everything we want in a form we want. while .st is for storing purely smalltalk source code, and nothing else. -- Best regards, Igor Stasenko.

Feb. 1, 2012

Re: [Pharo-project] Issue 5229: Removing the global use of UserInterruptHandler in favor of an inst var in the current Sensor

by Igor Stasenko

err... you seems like crossing multiple layers by doing that. Because before you were able to have interrupt handler without having a sensor. Now you cannot have interrupt handler without having sensor installed. On 1 February 2012 14:14, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Please integrate/review this one. > > > In the context of replacing the current event handling mechanism, for > the new Event-Model using announcements, i found out that the > UserInterruptHandler is somehow treated as a global. > > See > > Â InputEventSensor>>installEventSensorFramework: fetcherClass. > Â Â â¦. > Â Â "Register the interrupt handler" > Â Â UserInterruptHandler new registerIn: InputEventFetcher default. > Â Â â¦â¦. > > What if you want to replace the user interrupt handler for another? It > cant be done transparently. > > I've added the userInterruptHandler as an ivar of the current Sensor, > so when it registers and unregisters, it takes care of registering and > unregistering its user interrupt handler. > > So you can plug different user interrupt handlers to the current sensor. > > > > > Fernando > -- Best regards, Igor Stasenko.

Feb. 1, 2012

Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?

by Frank Shearar

On 1 February 2012 14:44, Damien Pollet <damien.pollet(a)gmail.com> wrote: > On 31 January 2012 15:59, Otto Behrens <otto(a)finworks.biz> wrote: >> I was wondering more if it is possible to do without having a file >> system checkout of the class definition. In other words, if the class >> definition in the image could serve as the working copy of the object >> in the git repository. I must read more on what the other guys did >> with the git interfaces (such as gitfs and gitosis) to understand what >> it comes down to. >> >> If this is possible, it would make merging, loading and committing >> essentially one step. > > Have you seen what Camillo did? > http://www.squeaksource.com/FSGit > https://github.com/dh83/fs-git-test > > Note the layout with class comment in a README file, etc :) That is _exactly_ the right thing to do! Bravo, Camillo! Also note how Nested-Package-Names end up looking like you might expect. Is there any necessity for storing a chunk? For instance in https://github.com/dh83/fs-git-test/blob/master/AAA/AAA.class/instance-side… we have !AAA methodsFor: 'as yet unclassified' stamp: 'CamilloBruni 1/23/2012 19:15'! a | a | ^ a! ! with the ugly chunk !s. The only thing we can't directly regenerate is the timestamp: modulo that, we know the class name, the category (the name of the directory you're in), the author (from the author of the git commit). You'd have a disconnect between the git commit time and the time in the chunk which would, IIRC, be the time you hit Alt-S in your browser? Or would that be file-out time, which would likely then be the timestamp in the git commit? > There is a also nearly working implementation of the git network > protocol (stubbed using the git binaries ATM). > > >> The disadvantage could be a tight coupling with git. > > is that really a disadvantage, compared to a tight coupling with monticello? With the added advantage of the git ecosystem thrown in for free - git hosting, rss feeds on git repositories, and a host of other things that would not need to be reinvented for Smalltalk. Letting us, to get to the punchline, do _more interesting work_. frank > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Feb. 1, 2012

Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?

by Damien Pollet

On 31 January 2012 15:59, Otto Behrens <otto(a)finworks.biz> wrote: > I was wondering more if it is possible to do without having a file > system checkout of the class definition. In other words, if the class > definition in the image could serve as the working copy of the object > in the git repository. I must read more on what the other guys did > with the git interfaces (such as gitfs and gitosis) to understand what > it comes down to. > > If this is possible, it would make merging, loading and committing > essentially one step. Have you seen what Camillo did? http://www.squeaksource.com/FSGit https://github.com/dh83/fs-git-test Note the layout with class comment in a README file, etc :) There is a also nearly working implementation of the git network protocol (stubbed using the git binaries ATM). > The disadvantage could be a tight coupling with git. is that really a disadvantage, compared to a tight coupling with monticello? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Feb. 1, 2012

[Pharo-project] pdf4smalltalk Re: pharo vision

by Ben Coman

It took some hunting but I finally found the source located here... http://pdf4smalltalk.origo.ethz.ch/wiki/store_access with MIT License specified here... http://pdf4smalltalk.origo.ethz.ch/ That looks quite promising. cheers, Ben StÃ©phane Ducasse wrote: > On Jan 31, 2012, at 5:13 PM, Ben Coman wrote: > > >> Stef, >> >> I've sent some markup directly, some additional ideas - perhaps only for later and/or more of a library than core functionality. >> >> Improved printing subsystem - by which I mean PDF output. >> Business proposition: Without good PDFs many contemporary business practices are curtailed. For example, multi-page reporting charts being emailed to external clients. >> > > Are you aware of the open-source library of Christian Haider? > > >> Running multiple images on one VM with copy-on-write shared memory. >> Business proposition: To allow more images (owned by different clients) to be run (presumably) with less resources on resource limited web server platforms. >>

Feb. 1, 2012

[Pharo-project] [update 1.4] #14301

by Marcus Denker

14301 ----- Issue 5226: Add 2 methods in Browser API to allow to easily register groups http://code.google.com/p/pharo/issues/detail?id=5226 Issue 5225: Remove PseudoContext http://code.google.com/p/pharo/issues/detail?id=5225 -- Marcus Denker -- http://marcusdenker.de

Feb. 1, 2012

[Pharo-project] Issue 5229: Removing the global use of UserInterruptHandler in favor of an inst var in the current Sensor

by Fernando Olivero

Please integrate/review this one. In the context of replacing the current event handling mechanism, for the new Event-Model using announcements, i found out that the UserInterruptHandler is somehow treated as a global. See InputEventSensor>>installEventSensorFramework: fetcherClass. â¦. "Register the interrupt handler" UserInterruptHandler new registerIn: InputEventFetcher default. â¦â¦. What if you want to replace the user interrupt handler for another? It cant be done transparently. I've added the userInterruptHandler as an ivar of the current Sensor, so when it registers and unregisters, it takes care of registering and unregistering its user interrupt handler. So you can plug different user interrupt handlers to the current sensor. Fernando

Feb. 1, 2012

Re: [Pharo-project] Re : a problem with a MorphTreeMorph with headers

by Esteban Lorenzano

http://code.google.com/p/pharo/issues/detail?id=5228 Thanks Alain! Esteban El 01/02/2012, a las 6:37a.m., Alain Plantec escribiÃ³: > Hi Esteban, > I think it is fixed in 1.4. > But I guess you are using 1.3, > I will fix that for 1.3 also, can you open an issue? > Cheers > Alain > De : Esteban Lorenzano <estebanlm(a)gmail.com> > Ã : Pharo Development <pharo-project(a)lists.gforge.inria.fr>; Moose-related development <moose-dev(a)iam.unibe.ch> > EnvoyÃ© le : Mardi 31 janvier 2012 23h07 > Objet : [Pharo-project] a problem with a MorphTreeMorph with headers > > Hi, > > I have a problem for an application I have: I'm displaying a MorphTreeMorph who has a header and some columns, problem is when morph has a horizontal scrollbar and I need to go down, last element on list is covered by horizontal scroll bar and customer can't see his data. > I need to solve this, but I don't know how, any help will be really appreciated. > > (the attached image shows my problem) > > thanks, > Esteban > > > > > >

Feb. 1, 2012