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

Re: [Pharo-project] Artefact - a PDF framework

by Olivier Auverlot

Hi GastÃ³n, Thanks for your remarks. I need of feedback for the road map. Artefact is like a baby ;-) Best regards Olivier > and you can use "transposed" for more elegantly :) > > * In PDFFormat>>setPortrait and >>setLandscape maybe #defaultSize > should be used instead of #size to get size, because otherwise, > two consecutive #setLandscape result in a portrait size. > > setPortrait > "Set the page in portrait orientation" > self portrait: true. > self size: (self defaultSize x) @ (self defaultSize y). > > > setLandscape > "Set the page in landscape orientation" > self portrait: false. > self size: self defaultSize transposed > > Regards.

April 25, 2012

[Pharo-project] initialize

by blake

OK, So, I'm writing a class and I have an initialize method. Well, I have two, actually, a class initialize and an instance initialize. And when I save it, the Nautilus browser shows it with a red flag in the gutter next to the instance method "initialize". And sure enough, instead of being called when I crate a new instance, the superclass' initialize is called instead. I can't figure it out. I have other classes that are virtually identical, structurally and they don't have the problem. So I remove the instance initialize method and then paste it back in. Red flag is gone, instance initialize is now being called. And instead of the red flag I get a green override arrow. What happened? ===Blake===

April 25, 2012

Re: [Pharo-project] Artefact - a PDF framework

by Olivier Auverlot

Hi Gary, > if you'd like any help with fonts and images I can assist. > Perviously I've implemented those things on top of SPDF. > yes. Thanks ;-) I will add you to the team (me and you in fact) > Regards, Gary > > ----- Original Message ----- > *From:* Olivier Auverlot <mailto:olivier.auverlot@gmail.com> > *To:* Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@lists.gforge.inria.fr> > *Sent:* Wednesday, April 25, 2012 9:15 AM > *Subject:* [Pharo-project] Artefact - a PDF framework > > Hi, > > I work actually on a PDF framework for Pharo. > > MCHttpRepository > location: 'http://www.squeaksource.com/artefact' > <http://www.squeaksource.com/artefact%27> > user: '' > password: '' > > My project is in progress and many things are not finalized (no > documentation, not enough unit tests, etc.). But, you can produce > PDF documents with metadata, multiple page formats in a same > document, draw tables, write text and paragraphs, play with colors > and grey levels. > > If you test it, thanks for your remarks and suggestions. > > Best regards > Olivier ;-) > www.auverlot.fr <http://www.auverlot.fr> >

April 25, 2012

Re: [Pharo-project] Nautilus for Pharo 2.0?

by Benjamin

Since a couple of minutes, Nautilus is part of Nautilus 2.0 Ben On Apr 25, 2012, at 6:17 PM, Noury Bouraqadi wrote: > Any plans to have an auto-build on Jenkins? > > Noury > -- > http://twitter.com/#!/NouryBouraqadi > http://www.kroobe.com/profile/noury > > > Afin de contribuer au respect de l'environnement, > merci de n'imprimer ce courriel qu'en cas de necessite > > Please consider the environment before you print > > > >

April 25, 2012

Re: [Pharo-project] Pharo and the rest of the ecosystem

by Chris Muller

I see the "point" of Cuis as to have a small, clean, understandable Smalltalk system. It's a *general-purpose* system rather than one geared solely towards business. Pharo, at least to me, feels more like the Java ecosystem -- a platform aiming primarily toward business and generating plenty of marketing "buzz" with frameworks-of-the-month (such as the ones you listed). In Cuis, Smalltalk _is_ the framework and users are expected to build on that directly. In my view, Spoon is about letting the machine generate a small, vertical system from a larger, horizontal system. Pavel, Edgar and you all have been working on making a smaller system for years (good work); but I see the dream of Spoon as delegating that work to the machine, which will do it quickly and accurately. The question at the moment is whether that dream will be realized. Based on Craig's Squeak-Board candidacy announcement, I expect 2012 to be the year Spoon is born into mainstream-use at least in the Squeak community. On Tue, Apr 24, 2012 at 4:22 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > May I ask you why you talk about CUIS and Spoon/Pharo? > If you want to work with these systems we do not have any problems. > > We are working on Pharo since 2008. We deliver regularly, we are concerned with > making sure that you can do business with Pharo. And we will continue. > WE want to invent and build OUR future. > > We are spending a lot of time on making the system better. > Â Â Â Â - Fuel > Â Â Â Â - Athens > Â Â Â Â - OPAL > Â Â Â Â - Ghost > Â Â Â Â - Nautilus > Â Â Â Â - Ring > Â Â Â Â - NativeBoost > Â Â Â Â - Zinc > Â Â Â Â - HUGE amount of fixes > Â Â Â Â - Working on a core > Â Â Â Â - Writing a lot of documentation (yes guys) > to name a few. We are pushing like hell and getting there. > > We spent time building our vision and step by step building it. We are getting there. Â :) > Now I do not see the points related to spoon and cuis. I do not understand what is the point. > If people wants to collaborate with us this is ok now we do not count on that for our future. > > You do not have to reply. Just think about what you want to build and your future. Everybody > make choices and is free. > > Stef > > >

April 25, 2012

[Pharo-project] Nautilus for Pharo 2.0?

by Noury Bouraqadi

Any plans to have an auto-build on Jenkins? Noury -- http://twitter.com/#!/NouryBouraqadi http://www.kroobe.com/profile/noury Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print

April 25, 2012

Re: [Pharo-project] PetitSmalltalk: now with a self-contained grammar for number literals

by Frank Shearar

On 20 April 2012 15:15, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 20 April 2012 03:51, Levente Uzonyi <leves(a)elte.hu> wrote: >> On Thu, 19 Apr 2012, Frank Shearar wrote: >> >>> I found a serious bug in parsing numbers with negative exponents. It >>> was completey broken, in fact, parsing 1e-1 as 10, not 1 / 10. Anyway. >>> This version fixes that, and adds a bunch of tests demonstrating that >>> number parsing will return rationals if it can. >>> >>> It's significantly slower than Squeak's SqNumberParser: >>> >>> Time millisecondsToRun: [100000 timesRepeat: [SqNumberParser parse: >>> '1234567890']] => 466 >>> >>> Time millisecondsToRun: [100000 timesRepeat: [PPSmalltalkNumberParser >>> parse: '1234567890']] => 32082 >>> >>> I've attached a MessageTally spying on the latter: I've not much skill >>> in reading these, but nothing leaps out at me as being obviously >>> awful. >> >> >> Didn't check the code, just the tally, and I think that >> PPSmalltalkNumberParser(PPSmalltalkNumberGrammar)>>digitsBase: is begging >> for optimization. It's probably also the cause of the high amount of garbage >> which causes significant amount of time spent with garbage collection. >> It's also interesting is that the finalization process does so much work, >> there may be something wrong with your image. > > Thanks for taking a look, Levente. > > I'd expect digitsBase: to dominate the running costs, given that we're > parsing numbers. > > I do make a large number of throwaway "immutable" values with a > Builder-like pattern... in PPSmalltalkNumberParser >> > #makeNumberFrom:base:. That, I would imagine, could explain the > garbage? > > If I may, what do you look for when reading the MessageTally? How do > you tell, for instance, that there's excessive garbage production? > That the incremental GCs take 7ms? (I'm reading Andreas' comments on > http://wiki.squeak.org/squeak/4210 again.) Levente, you're quite right: #digitsBase: has now been optimised even more, reducing the time taken to run my benchmark MessageTally spyOn: [Time millisecondsToRun: [100000 timesRepeat: [PPSmalltalkNumberParser parse: '1234567890']]] from ~32 seconds to ~16 seconds. (Memoising was the answer: #digitsBase: is effectively a higher-order production and, like OMeta, PPCompositeParser doesn't memoise those. A simple class var dictionary solves that problem. frank > frank > >> Levente >> >> >>> >>> frank >>> >>> On 14 September 2011 20:26, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>> >>>> On 3 September 2011 19:35, Nicolas Cellier >>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>> >>>>> 2011/9/3 Frank Shearar <frank.shearar(a)gmail.com>: >>>>>> >>>>>> On 3 September 2011 18:50, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>>>> >>>>>>> I think it is a good idea to have the number parser separate, after >>>>>>> all it might also make sense to use it separately. >>>>>>> >>>>>>> It seems that the new Smalltalk grammar is significantly slower. The >>>>>>> benchmark PPSmalltalkClassesTests class>>#benchmark: that uses the >>>>>>> source code of the collection hierarchy and does not especially target >>>>>>> number literals runs 30% slower. >>>>>>> >>>>>>> Also I see that "Number readFrom: ..." is still used within the >>>>>>> grammar. This seems to be a bit strange, no? >>>>>> >>>>>> >>>>>> Yes: it's a double-parse, which is a bit lame. First, we parse the >>>>>> literal with PPSmalltalkNumberParser, which ensures that the thing >>>>>> given to Number class >> #readFrom: is a well-formed token (so, in >>>>>> particular, Squeak's Number doesn't get to see anything other than a >>>>>> well-formed token). >>>>>> >>>>>> It sounds like you're happy with the basic concept, so maybe I should >>>>>> remove the Number class >> #readFrom: stuff, see if I can't remove the >>>>>> performance issues, and resubmit the patch. >>>>>> >>>>>> frank >>>>>> >>>>> >>>>> Yes, a NumberParser is essentially parsing, and this duplication sounds >>>>> useless. >>>>> The main feature of interest in NumberParser that I consider a >>>>> requirement and should find its equivalence in a PetitNumberParser is: >>>>> - round a decimal representation to nearest Float >>>>> It's simple, just convert a Fraction asFloat in a single final step to >>>>> avoid cumulating round off errors - see >>>>> #makeFloatFromMantissa:exponent:base: >>>>> >>>>> The second feature of interest in NumberParser is the ability to >>>>> parser LargeInteger efficiently by avoiding (10 * largeValue + >>>>> digitValue) loops, and replacing them with a log(n) cost. >>>>> This would be a simple thing to implement in a functional language. >>>> >>>> >>>> Hopefully this won't offend your sensibilities too much :). It does, >>>> in fact, use 10* loops - I wrote an experimental "front half * rear >>>> half" recursion, which was slower in my benchmarks. >>>> >>>> This version has the grammar and parser doing no string->number >>>> conversion at all. PPSmalltalkNumberMaker supplies a number of utility >>>> methods designed to stop one from making malformed numbers. It also >>>> supplies a builder interface that the parser uses to construct >>>> numbers. >>>> >>>> frank >>>> >>>>> Nicolas >>>>> >>>>>>> Lukas >>>>>>> >>>>>>> >>>>>>> On 3 September 2011 17:18, Frank Shearar <frank.shearar(a)gmail.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> On 3 September 2011 15:56, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>> On 3 September 2011 16:51, Frank Shearar <frank.shearar(a)gmail.com> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Lukas, >>>>>>>>>> >>>>>>>>>> I haven't :) mainly because I'm unsure where to put it - is there >>>>>>>>>> perhaps a PP Inbox, or shall I just post the merged version, or >>>>>>>>>> what's >>>>>>>>>> your preference? (How about an mcd between my merge and PP's head?) >>>>>>>>> >>>>>>>>> >>>>>>>>> Just put the .mcz at some public URL (dropbox, squeak source, ...) >>>>>>>>> or >>>>>>>>> attach it to a mail. >>>>>>>> >>>>>>>> >>>>>>>> Ah, great - here it is. You'll see I've written the grammar as a >>>>>>>> separate class. That was really more to make what I'd done more >>>>>>>> obvious and to minimise the change to PPSmalltalkGrammar, but perhaps >>>>>>>> it's not a bad idea anyway: it's easy to see the number literal >>>>>>>> subgrammar. >>>>>>>> >>>>>>>> frank >>>>>>>> >>>>>>>>> Lukas >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Lukas Renggli >>>>>>>>> www.lukas-renggli.ch >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Lukas Renggli >>>>>>> www.lukas-renggli.ch >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>> >>

April 25, 2012

[Pharo-project] [update 1.4] #14439

by Esteban Lorenzano

14439 ----- Issue 5665: bug on new ecompletion/ocompletion http://code.google.com/p/pharo/issues/detail?id=5665 Also, fix for VM: Issue 5609: Pharo 1.4 Windows VM crashes with FFI Tests http://code.google.com/p/pharo/issues/detail?id=5609 this fixes are ready on: https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/Architecture=32,OS=win/… and https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4/lastSucces… (also on 2.0 unstable)

April 25, 2012

Re: [Pharo-project] Downloading a file

by Igor Stasenko

On 25 April 2012 17:13, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > ZnClient new get: > 'https://ci.lille.inria.fr/pharo/job/Cog%20Git%20Tracker/lastSuccessfulBuild…'. > > Reports entity too large. How do I save this file to local disk? > this is situation where using stream is preferable. Sven already told how to use it.. i just don't remember how. > Thanks. > Sean > > -- > View this message in context: http://forum.world.st/Downloading-a-file-tp4586900p4586900.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

April 25, 2012

[Pharo-project] [update 2.0] #20011

by Esteban Lorenzano

20011 ----- introducing: -RPackage -Spec -Keymapping -Refactoring Engine -AST -Nautilus - Issue 5665: bug on new ecompletion/ocompletion http://code.google.com/p/pharo/issues/detail?id=5665 - Issue 5671: Polymorph fixes http://code.google.com/p/pharo/issues/detail?id=5671

April 25, 2012