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

Re: [Pharo-project] TxText progress and discussion

by Denis Kudriashov

Hi 2013/3/31 stephane ducasse <stephane.ducasse(a)free.fr> > Hello deni > > this is great to see your effort on that side of the front :) > One question: > do you paste all these explanation in class side comments :)? > > I will doing this > >> I want easily understand what kind of position method means. In > TxLayoutSpan > >> I try to distinct it by "charPosition" and "xyPosition". I dont sure it > is > >> nice. > >> > > > > How about textPosition and visualPosition/layoutPosition? > > So you know that it speaking either about position in text or layout > > position (x/y). > > +1 > > > > >> And I don't like name of TxLayoutSpan. (too many spans). > >> > > > > well, it represents a portion of text, laid out in some view. so, > > layout span is logical name for it. > > > >> Small tasks which I have in mind: > >> - more cursor movement actions > >> - make settings for shortcuts at TxTextMorph > >> - make cursor actions dynamically connected to shortcut settings. Each > >> cursor action (method) should automatically creates shortcut setting > for it. > >> > >> There is strange problem with TxTextMorph when it is transparent. Try > change > >> #drawOn: method to see it (remove rectangle filling). > >> > >> Next I will implement events logic to update TxLayoutPosition when > layout > >> changed. And text selection stuff. > >> > > > > What an impressive amount of progress! Too bad i had no time to work on > it.. > > but during next couple month i will allocate time (in context of > > working with Athens), > > to spend on it, and adopt it for athens rendering. > > :) > > >

March 31, 2013

Re: [Pharo-project] PDF Rendering

by Christian Haider

My name is Haider (sticky fingers are not polite with proper names...). My PDF library has nothing to do with rendering (putting the graphics on the screen) and I doubt that Artefact will do that. IMHO, rendering PDF is quite a challenge... Cheers, Christian (HAIDER) > -----UrsprÃ¼ngliche Nachricht----- > Von: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project- > bounces(a)lists.gforge.inria.fr] Im Auftrag von stephane ducasse > Gesendet: Sonntag, 31. MÃ¤rz 2013 11:16 > An: Pharo-project(a)lists.gforge.inria.fr > Betreff: Re: [Pharo-project] PDF Rendering > > Else there is also the work of Christian Haidler. > Artefact developers will release soon a 0.9 version once they fix the jpeg > inclusion Stef > > >> I was looking around for PDF rendering libraries that might be used with > NativeBoost and they all seem to be licensed GPL, which is not compatible > with Pharo's preference for the MIT license. Then I came across Apache > licensed pdf.js [1] which sparked my curiosity.... There are a few projects to > have Smalltalk run on top of Javascript, but has anyone looked at the > reverse, running javascript inside a Smalltalk image? Perhaps handing the > Javascript off via NativeBoost to a Javascript VM like SquirrelFish [2]. Or is > that just a bad idea? > >> > >> cheers -ben > >> > >> [1] http://andreasgal.com/2011/06/15/pdf-js/ > >> [2] https://www.webkit.org/blog/189/announcing-squirrelfish/ > > > > Maybe you already knew about Artefact - a PDF framework for Pharo > > > > http://forum.world.st/Artefact-a-PDF-framework-td4585877.html > > > > A solution in Smalltalk is more useful in the long term, IMHO, in the sense > that it can then be read, understood, maintained by the community instead > of being a black box. > > > > Sven > > > > -- > > Sven Van Caekenberghe > > http://stfx.eu > > Smalltalk is the Red Pill > > > > > > >

March 31, 2013

Re: [Pharo-project] [update 3.0] #30016

by Camillo Bruni

On 2013-03-31, at 11:12, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-03-31, at 11:08, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> camillo >> >> I do not announce the update before the 4 stages are run and green. >> This slows us down so we code in between updates but this is using the stagged process. >> I do not even know how you can determine that we are not using it :). > > I just check when you announced the update and I see that the last update was > present in both lists (updates30.list and updates30.staged) while jenkins was > still validating the update. This makes a bit suspicious :) since technically > this state is impossible (well there are bugs of course ;)) > > 1. new updates prepared > 2. updates are put into updates30.staged > 3. change triggers jenkins > 4. changes are validated > 5. updates30.staged is copied into updates30.list, only here at this point can we have two updates present in both files > 6. updates30.staged is deleted and this is where the bug happened ;) udpates30.staged was never properly deleted. sorry for the noise :P

March 31, 2013

Re: [Pharo-project] [update 3.0] #30016

by Camillo Bruni

On 2013-03-31, at 11:08, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > camillo > > I do not announce the update before the 4 stages are run and green. > This slows us down so we code in between updates but this is using the stagged process. > I do not even know how you can determine that we are not using it :). I just check when you announced the update and I see that the last update was present in both lists (updates30.list and updates30.staged) while jenkins was still validating the update. This makes a bit suspicious :) since technically this state is impossible (well there are bugs of course ;)) 1. new updates prepared 2. updates are put into updates30.staged 3. change triggers jenkins 4. changes are validated 5. updates30.staged is copied into updates30.list, only here at this point can we have two updates present in both files 6. updates30.staged is deleted > Stef > > On Mar 29, 2013, at 3:46 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> why is the new update already in >> http://pharo.gforge.inria.fr/updates/pharo3.0/updates30.list >> >> when it is still present in the staged file? >> http://pharo.gforge.inria.fr/updates/pharo3.0/updates30.staged >> >> does that mean that the staged update process isn't used properly yet? >> >> On 2013-03-29, at 15:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> >>> 30016 >>> ----- >>> >>> 10168 Spec new layout management >>> https://pharo.fogbugz.com/f/cases/10168 >>> >>> >>> Diff information: >>> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Spec-Layout-StephaneDucasse.… >>> >>> >>> Stef ;) >>> >> >> > >

March 31, 2013

Re: [Pharo-project] [update 3.0] #30016

by stephane ducasse

camillo I do not announce the update before the 4 stages are run and green. This slows us down so we code in between updates but this is using the stagged process. I do not even know how you can determine that we are not using it :). Stef On Mar 29, 2013, at 3:46 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > why is the new update already in > http://pharo.gforge.inria.fr/updates/pharo3.0/updates30.list > > when it is still present in the staged file? > http://pharo.gforge.inria.fr/updates/pharo3.0/updates30.staged > > does that mean that the staged update process isn't used properly yet? > > On 2013-03-29, at 15:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> 30016 >> ----- >> >> 10168 Spec new layout management >> https://pharo.fogbugz.com/f/cases/10168 >> >> >> Diff information: >> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Spec-Layout-StephaneDucasse.… >> >> >> Stef ;) >> > >

March 31, 2013

Re: [Pharo-project] [Pharo-users] [ANN] Fuel Release Version 1.9

by stephane ducasse

Thanks guys this is great. I'm really happy to see that the effort we started two years ago is paying off. Stef On Mar 28, 2013, at 6:40 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi all, > > We are happy to announce Fuel 1.9. > > Fuel is an open-source general-purpose object serialization framework developed in Pharo. You can find more information on our website [1]. > > The default set of packages of this version already comes in Pharo 2.0, so you it's not necessary to install it there. However, Fuel also works out-of-the-box in Pharo from 1.1 up to 2.0, as well as in Squeak 4.1 up to 4.4. You can see our documentation [2] for complete installation and use guides. > > Changes: > > - (feature) DoIt and not-installed CompiledMethods are fully serialized by default. > - (fix) Date & DateAndTime (thanks Cami and Marcus) (already included in Fuel 1.8.1 and 1.8.2). > - (feature) New hooks methods #fuelNew and #fuelNew: for custom instantiation (see "Hooking instance creation" in Customizing the Graph). > - Globals: > - Added #globalEnvironment: to specify where the globals are looked-up. (see "Changing the environment" in Managing Globals). > - Explicit references to "Smalltalk globals" changed to "self class environment". > - A SystemDictionary instance is not treated as global when it is not "Smalltalk globals". > - Documentation: > - General update > - New Format Migration section. > - New Built-in Header Support section. > - (feature) Put back FLSerializer>>on:. > - (optimization) New clusters for SmallInteger. > - (optimization) New clusters for most common collections. > - (feature) Built-in support for header (See Built-in Header Support): > - pre and post materialization actions (clean closures). > - attach additional objects. > - materialize only the header. > - (fix) Safer substitutions (see FLPluggableSubstitutionTest>>testPrivateExcluded). > - (feature) Materialize .fuel files when drag&dropped in the image. > - (cleanup) Removed unneeded cluster: FLWellKnownObjectsCluster. > > [1]: http://rmod.lille.inria.fr/web/pier/software/Fuel > [2]: http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.9/Documentation > > We want to thank developers of the community that enrich the project with code, issue reports and ideas. > > Have fun! > > Martin (on behalf of Mariano and Max, who worked a lot on this version)

March 31, 2013

Re: [Pharo-project] PDF Rendering

by stephane ducasse

Else there is also the work of Christian Haidler. Artefact developers will release soon a 0.9 version once they fix the jpeg inclusion Stef >> I was looking around for PDF rendering libraries that might be used with NativeBoost and they all seem to be licensed GPL, which is not compatible with Pharo's preference for the MIT license. Then I came across Apache licensed pdf.js [1] which sparked my curiosity.... There are a few projects to have Smalltalk run on top of Javascript, but has anyone looked at the reverse, running javascript inside a Smalltalk image? Perhaps handing the Javascript off via NativeBoost to a Javascript VM like SquirrelFish [2]. Or is that just a bad idea? >> >> cheers -ben >> >> [1] http://andreasgal.com/2011/06/15/pdf-js/ >> [2] https://www.webkit.org/blog/189/announcing-squirrelfish/ > > Maybe you already knew about Artefact - a PDF framework for Pharo > > http://forum.world.st/Artefact-a-PDF-framework-td4585877.html > > A solution in Smalltalk is more useful in the long term, IMHO, in the sense that it can then be read, understood, maintained by the community instead of being a black box. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

March 31, 2013

Re: [Pharo-project] TxText progress and discussion

by stephane ducasse

Hello deni this is great to see your effort on that side of the front :) One question: do you paste all these explanation in class side comments :)? >> I want easily understand what kind of position method means. In TxLayoutSpan >> I try to distinct it by "charPosition" and "xyPosition". I dont sure it is >> nice. >> > > How about textPosition and visualPosition/layoutPosition? > So you know that it speaking either about position in text or layout > position (x/y). +1 > >> And I don't like name of TxLayoutSpan. (too many spans). >> > > well, it represents a portion of text, laid out in some view. so, > layout span is logical name for it. > >> Small tasks which I have in mind: >> - more cursor movement actions >> - make settings for shortcuts at TxTextMorph >> - make cursor actions dynamically connected to shortcut settings. Each >> cursor action (method) should automatically creates shortcut setting for it. >> >> There is strange problem with TxTextMorph when it is transparent. Try change >> #drawOn: method to see it (remove rectangle filling). >> >> Next I will implement events logic to update TxLayoutPosition when layout >> changed. And text selection stuff. >> > > What an impressive amount of progress! Too bad i had no time to work on it.. > but during next couple month i will allocate time (in context of > working with Athens), > to spend on it, and adopt it for athens rendering. :)

March 31, 2013

Re: [Pharo-project] FileSystem-Legacy fixes

by Johan Brichau

Allright. I will take care of that. Johan (sent from my mobile) On 30 Mar 2013, at 20:54, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Yes that sounds like a good idea. > and we should move it then to PharoExtras. > > I created http://smalltalkhub.com/#!/~PharoExtras/FileSystemLegacy/ and added you as a contributor. > Could you copy over the contents from http://smalltalkhub.com/#!/~dh83/fisleg ? > and maybe create a configuration? > > thanks a lot! > > On 2013-03-30, at 09:17, Johan Brichau <johan(a)inceptive.be> wrote: > >> Hi Pharoers, >> Hi Camillo, >> >> To make Seaside3.0.x work in Pharo2.0, we included the FileSystem-Legacy package. >> (this is probably the easiest solution for Seaside3.0.x branch) >> >> I did need to make some changes because this package had a slightly different behavior than the legacy code in some methods: >> - add #primPathNameDelimiter >> - #directoryExists: should not only check if it exists, it should also check if it's a directory: >> (self resolve: filenameOrPath) exists and:[(self resolve: filename) isDirectory] >> - #directoryNamed: was actually able to accept a fully qualified pathName as an argument (not logical, but that's legacy ;-). So implemented as follows: >> FileDirectory on: (self fullNameFor: localFileName) >> >> What do you think? >> Can I publish these changes to the FileSystem package? >> >> regards >> Johan >

March 31, 2013

Re: [Pharo-project] icons in Nautilus?

by jannik.laval

I think for now that a help button could be enough with a small description of each button. Jannik On Mar 31, 2013, at 8:01 AM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > We tried that we Jannik, but it was complicated :) > > But yes, I will try to put some effort here :) > > Ben > > On Mar 31, 2013, at 3:25 AM, jannik.laval <jannik.laval(a)gmail.com> wrote: > >> Inside pharo would be cool ;) >> >> --- >> Jannik Laval >> >> Le 30 mars 2013 Ã 23:41, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> a Ã©crit : >> >>> http://rmod.lille.inria.fr/web/pier/software/Tools-Improvement/NautilusDocu… >>> >>> Ben >>> >>> On Mar 30, 2013, at 11:28 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>>> Maybe we should write somewhere an explanation to all icons? >>>> >>>> Is it possible to do it in help? >>>> >>>> uko >>>> >>>> >>>> On 30 Ð±ÐµÑ. 2013, at 22:44, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>>> >>>>> The first one means the package is empty >>>>> >>>>> the second one that this package is a probably monticello package (no classes, only extensions) >>>>> >>>>> Ben >>>>> >>>>> On Mar 30, 2013, at 5:09 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>>> >>>>>> Hi! >>>>>> >>>>>> I am just wondering what these icons means in Nautilus >>>>>> >>>>>> <Screen Shot 2013-03-30 at 12.08.35 PM.png> ?? >>>>>> >>>>>> <Screen Shot 2013-03-30 at 12.08.42 PM.png> a method extension that is not properly packaged? >>>>>> >>>>>> Cheers, >>>>>> Alexandre >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >

March 31, 2013