- Pharo-dev - lists.pharo.org

Re: [Pharo-project] cannot modify class comments on Linux

by Marcus Denker

> > well, it have to be so.. but if it breaks existing code, then it could > mean that libc turned from implicit caching/buffering to explicit one. > And this could mean many changes here and there. > (Besides of that, i never liked RemoteString and other things related > to writing to .changes file... > that code begs for proper rewrite) The whole .changes and .source code is extremely complicated considering for what it gets us. Marcus

April 26, 2013

Re: [Pharo-project] RE : cannot modify class comments on Linux

by Igor Stasenko

On 26 April 2013 13:15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 26 Apr 2013, at 12:44, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 26 April 2013 10:27, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> The reason is in the optimalizations in the latest glibc. It really does not >>> write the new content to the changes file immediately. We need to call flush >>> at the end of nextChunkPut: >>> >> This is nasty one. >> What i worry that it affects much more than code working with .changes file. > > Why ? Isn't that standard behavior/semantics: unless you flush you cannot be sure anything is actually out of the OS' buffers. And even then, disks and RAID cards are known to lie and sometimes don't write data out even when flush is called. > well, it have to be so.. but if it breaks existing code, then it could mean that libc turned from implicit caching/buffering to explicit one. And this could mean many changes here and there. (Besides of that, i never liked RemoteString and other things related to writing to .changes file... that code begs for proper rewrite) > In networking (TCP streams) this is similar. > >>> Cheers, >>> -- Pavel >>> >>> >>> On Fri, Apr 26, 2013 at 9:57 AM, GOUBIER Thierry <thierry.goubier(a)cea.fr> >>> wrote: >>>> >>>> Reproduced on Ubuntu 13.04. >>>> >>>> Class organization remoteString filePositionHi is past the end of the >>>> changes file (i.e. exactly equal to the file size if the comment is the last >>>> operation). >>>> >>>> Thierry >>>> ________________________________ >>>> De : pharo-project-bounces(a)lists.gforge.inria.fr >>>> [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Pavel Krivanek >>>> [pavel.krivanek(a)gmail.com] >>>> Date d'envoi : jeudi 25 avril 2013 21:32 >>>> Ã : Pharo-project(a)lists.gforge.inria.fr >>>> Objet : Re: [Pharo-project] cannot modify class comments on Linux >>>> >>>> Jaroslav wrote this: >>>> This does work on F17, but it doesn't work on F18, F19. Maybe glibc issue? >>>> I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15 same >>>> as F17, so I guess this would be also reproducible on Ubuntu 13.04. >>>> >>>> -- Pavel >>>> >>>> On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi <giseladecuzzi(a)gmail.com> >>>> wrote: >>>>> >>>>> I'm on 64-bit Ubuntu 12.04 >>>>> >>>>> >>>>> 2013/4/25 Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>>>> >>>>>> Hi, >>>>>> >>>>>> what architecture and distro do you use because I tried it on a 32-bit >>>>>> Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why >>>>>> the tests are not failing on CI. This error appears on all old system >>>>>> classes and on newely created classes too. >>>>>> Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376 >>>>>> >>>>>> -- Pavel >>>>>> >>>>>> On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi >>>>>> <giseladecuzzi(a)gmail.com> wrote: >>>>>>> >>>>>>> Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me. (just >>>>>>> try in a random class comment) >>>>>>> Are you trying to modify a particular class comment? >>>>>>> >>>>>>> >>>>>>> 2013/4/25 Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> if you will try to modify a class comment on Linux, the error >>>>>>>> "RemoteString past end of file" will appear. On windows VM it seems to work >>>>>>>> well. Can someone confirm this behavior on Linux. Squeak has the same >>>>>>>> problem. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> -- Pavel >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

April 26, 2013

Re: [Pharo-project] RE : cannot modify class comments on Linux

by Camillo Bruni

On 2013-04-26, at 12:44, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 26 April 2013 10:27, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> The reason is in the optimalizations in the latest glibc. It really does not >> write the new content to the changes file immediately. We need to call flush >> at the end of nextChunkPut: yet another reason to get rid of .changes and .sources! :)

April 26, 2013

Re: [Pharo-project] RE : cannot modify class comments on Linux

by Sven Van Caekenberghe

On 26 Apr 2013, at 12:44, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 26 April 2013 10:27, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> The reason is in the optimalizations in the latest glibc. It really does not >> write the new content to the changes file immediately. We need to call flush >> at the end of nextChunkPut: >> > This is nasty one. > What i worry that it affects much more than code working with .changes file. Why ? Isn't that standard behavior/semantics: unless you flush you cannot be sure anything is actually out of the OS' buffers. And even then, disks and RAID cards are known to lie and sometimes don't write data out even when flush is called. In networking (TCP streams) this is similar. >> Cheers, >> -- Pavel >> >> >> On Fri, Apr 26, 2013 at 9:57 AM, GOUBIER Thierry <thierry.goubier(a)cea.fr> >> wrote: >>> >>> Reproduced on Ubuntu 13.04. >>> >>> Class organization remoteString filePositionHi is past the end of the >>> changes file (i.e. exactly equal to the file size if the comment is the last >>> operation). >>> >>> Thierry >>> ________________________________ >>> De : pharo-project-bounces(a)lists.gforge.inria.fr >>> [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Pavel Krivanek >>> [pavel.krivanek(a)gmail.com] >>> Date d'envoi : jeudi 25 avril 2013 21:32 >>> Ã : Pharo-project(a)lists.gforge.inria.fr >>> Objet : Re: [Pharo-project] cannot modify class comments on Linux >>> >>> Jaroslav wrote this: >>> This does work on F17, but it doesn't work on F18, F19. Maybe glibc issue? >>> I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15 same >>> as F17, so I guess this would be also reproducible on Ubuntu 13.04. >>> >>> -- Pavel >>> >>> On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi <giseladecuzzi(a)gmail.com> >>> wrote: >>>> >>>> I'm on 64-bit Ubuntu 12.04 >>>> >>>> >>>> 2013/4/25 Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>>> >>>>> Hi, >>>>> >>>>> what architecture and distro do you use because I tried it on a 32-bit >>>>> Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why >>>>> the tests are not failing on CI. This error appears on all old system >>>>> classes and on newely created classes too. >>>>> Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376 >>>>> >>>>> -- Pavel >>>>> >>>>> On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi >>>>> <giseladecuzzi(a)gmail.com> wrote: >>>>>> >>>>>> Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me. (just >>>>>> try in a random class comment) >>>>>> Are you trying to modify a particular class comment? >>>>>> >>>>>> >>>>>> 2013/4/25 Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> if you will try to modify a class comment on Linux, the error >>>>>>> "RemoteString past end of file" will appear. On windows VM it seems to work >>>>>>> well. Can someone confirm this behavior on Linux. Squeak has the same >>>>>>> problem. >>>>>>> >>>>>>> Cheers, >>>>>>> -- Pavel >>>>>> >>>>>> >>>>> >>>> >>> >> > > > > -- > Best regards, > Igor Stasenko. >

April 26, 2013

Re: [Pharo-project] Pharo 3.1 meeting

by Benjamin

The monkey refers to Ulysse, not Penelope :) (we will soon have both Bruce Willis and Brad Pitt involved ^^ [1]) Penelope code as well as Ulysse one is on smalltalkhub/~Pharo/ci/main Basically we have a delay here which should update the cache, but some sh*t happened :s If you want to be involved, I can point you were the bad code is ^^ Ben [1] http://www.imdb.com/title/tt0114746/ On Apr 26, 2013, at 11:23 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-04-26, at 03:46, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > >> Does "update the monkey" refer to Penelope? > > yes. > We're almost there... completely redesigned from scratch with a nice API > to add validation rules and generate validation reports. Basically I was > sick the last month so there was not as much progress as I hoped ;). > > 1 or 2 more weeks and we have a shiny new monkey up and running. > >> I was going to ask whether we can start using the Penelope issue urls e.g. >> in the "[update 3.0]" posts, but then I checked the Penelope pages for the >> #30059 issues and: >> http://bugs.pharo.org/issues/id/10367 >> http://bugs.pharo.org/issues/id/10389 >> were two days behind the actual issue >> >> And http://bugs.pharo.org/issues/id/10356 reported 'MessageNotUnderstood: >> receiver of "joinUsing:" is nil'. Where is the Penelope code? Maybe we could >> help... didn't see it on sthub... >> >> Slightly OT, in the "[update 3.0]" posts, it'd be helpful to list the diffs >> under the issue they belong to instead of all together at the end. I.e. >> >> url1 >> diff1a >> diff1b >> url2 >> diff2 >> url3 >> diff3 >> >> instead of >> url1 >> url2 >> url3 >> diff? >> diff? >> diff? >> diff? >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Pharo-3-1-meeting-tp4683613p4683644.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

April 26, 2013

Re: [Pharo-project] Small(talk) opportunities

by Benjamin

I could be :) Ben On Apr 26, 2013, at 5:17 AM, DeNigris Sean <sean(a)clipperadams.com> wrote: > From time to time, I lead small commercial Smalltalk projects, parts of which I'm able to delegate. If you're interested in more details / participating when these come up, email me and I'll keep you in mind. > > Cheers, > Sean

April 26, 2013

Re: [Pharo-project] [FYI] Athens tutorial

by Igor Stasenko

On 26 April 2013 12:42, Mariano Vicente <m.vicent(a)gmail.com> wrote: > My apologies for the insufficient info.This happens after install the > tutorial, when i try to reopen the image > where i installed ahtens and the tutorial. > ah, ok. you seem also did the same thing: saved image with tutorial window open :) Btw, this should be fixed in newer version of tutorial. What package version you loaded? > Saludos, > Mariano > -- Best regards, Igor Stasenko.

April 26, 2013

Re: [Pharo-project] Smart Suggestion Version 1

by Esteban Lorenzano

well... we had a lot of things to improve in the usability field... starting by the fact that "usability" word is considered evil for the "usability experts" :) Esteban On Apr 26, 2013, at 10:29 AM, Gisela Decuzzi <giseladecuzzi(a)gmail.com> wrote: > I think that a good usability project can be implement the circular menus and give a try. > But in the other hand the suggestions tries to go in the way of smaller menus, only that instead of dependency in the graphic section has the dependency in the selected code (similar to control 1 in eclipse). > > Don't know, we need to collect some experience to reach a solution... and talking about that, smart suggestions it's itegrated in pharo 3.0 so if you download the last version can give a try and give some feedback to improve the tool. > > I will continue working in highlight the selection and try it with Rubric. > > > 2013/4/24 Stephan Eggermont <stephan(a)stack.nl> > Norbert wrote: > >First grey out things and the expert can switch them off to make disabled entries invisible. > > That's not what experts do, btw. Expert menu behavior is based on muscle memory. > Things always being in the same place is crucial. As well as predictable delays for > submenus, consistent width & height of the menus. > > Options are evil from a usability pov > > I took a detailed look: Nautilus menu items are not as tall as the other menus? That makes > them difficult to use, muscle memory fails here. > "Add Matching Packages as Groups and Browse" is definitely too long. Any suggestions > for a shorter text? > > A 2-dimensional menu (circle menu) would work better here, where the number of > elements is so high. Currently, the mouse travel distance is too large > > Camillo wrote: > >In the end, for most pro users, and by that I rely on my experience with very complex 3D software, > >menus are mostly there to learn the shortcuts. That means they do not have to be super navigable > >(e.g. one big list) but logically structured (e.g. submenus). > > That could be a reversal of cause and effect. I've seen too many complex old systems where the > old dos menu structure was simply moved to a context menu. That does not work at all. > > Stephan > > > > > >

April 26, 2013

Re: [Pharo-project] RE : cannot modify class comments on Linux

by Igor Stasenko

On 26 April 2013 10:27, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > The reason is in the optimalizations in the latest glibc. It really does not > write the new content to the changes file immediately. We need to call flush > at the end of nextChunkPut: > This is nasty one. What i worry that it affects much more than code working with .changes file. > Cheers, > -- Pavel > > > On Fri, Apr 26, 2013 at 9:57 AM, GOUBIER Thierry <thierry.goubier(a)cea.fr> > wrote: >> >> Reproduced on Ubuntu 13.04. >> >> Class organization remoteString filePositionHi is past the end of the >> changes file (i.e. exactly equal to the file size if the comment is the last >> operation). >> >> Thierry >> ________________________________ >> De : pharo-project-bounces(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Pavel Krivanek >> [pavel.krivanek(a)gmail.com] >> Date d'envoi : jeudi 25 avril 2013 21:32 >> Ã : Pharo-project(a)lists.gforge.inria.fr >> Objet : Re: [Pharo-project] cannot modify class comments on Linux >> >> Jaroslav wrote this: >> This does work on F17, but it doesn't work on F18, F19. Maybe glibc issue? >> I guess the reproducer needs glibc-2.16 and up, IMHO 12.04 has 2.15 same >> as F17, so I guess this would be also reproducible on Ubuntu 13.04. >> >> -- Pavel >> >> On Thu, Apr 25, 2013 at 11:16 AM, Gisela Decuzzi <giseladecuzzi(a)gmail.com> >> wrote: >>> >>> I'm on 64-bit Ubuntu 12.04 >>> >>> >>> 2013/4/25 Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>> >>>> Hi, >>>> >>>> what architecture and distro do you use because I tried it on a 32-bit >>>> Debian and it worked. I'm on 64-bit Fedora 18. That may be the reason why >>>> the tests are not failing on CI. This error appears on all old system >>>> classes and on newely created classes too. >>>> Some next info: https://bugzilla.redhat.com/show_bug.cgi?id=956376 >>>> >>>> -- Pavel >>>> >>>> On Thu, Apr 25, 2013 at 10:58 AM, Gisela Decuzzi >>>> <giseladecuzzi(a)gmail.com> wrote: >>>>> >>>>> Hi Pavel, I tried in Pharo 2.0 and 3.0 and it work well for me. (just >>>>> try in a random class comment) >>>>> Are you trying to modify a particular class comment? >>>>> >>>>> >>>>> 2013/4/25 Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>>>> >>>>>> Hi, >>>>>> >>>>>> if you will try to modify a class comment on Linux, the error >>>>>> "RemoteString past end of file" will appear. On windows VM it seems to work >>>>>> well. Can someone confirm this behavior on Linux. Squeak has the same >>>>>> problem. >>>>>> >>>>>> Cheers, >>>>>> -- Pavel >>>>> >>>>> >>>> >>> >> > -- Best regards, Igor Stasenko.

April 26, 2013

Re: [Pharo-project] [FYI] Athens tutorial

by Mariano Vicente

ââââMy apologies for the insufficient info.This happens after install the tutorial, when i try to reopen the image â where i installed ahtens and the tutorial.â Saludos, Mariano On Fri, Apr 26, 2013 at 7:29 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 26 April 2013 09:07, Mariano Vicente <m.vicent(a)gmail.com> wrote: > > Hi guys. After install the Athen's tutorial, I have had some error in > the > > image: > > > > Segmentation fault Fri Apr 26 03:59:42 2013 > > > > There is a problem over the image or my vm? > > I added the full log in the attached, > > > hard to say. > when/how it happens? > > > On Fri, Apr 12, 2013 at 4:53 AM, Tristan Bourgois > > <tristan.bourgois(a)gmail.com> wrote: > >> > >> > >> > >> > >> 2013/4/11 Igor Stasenko <siguctua(a)gmail.com> > >>> > >>> On 11 April 2013 10:44, Tristan Bourgois <tristan.bourgois(a)gmail.com> > >>> wrote: > >>> > > >>> > > >>> > > >>> > 2013/4/11 Igor Stasenko <siguctua(a)gmail.com> > >>> >> > >>> >> On 11 April 2013 08:55, Tristan Bourgois < > tristan.bourgois(a)gmail.com> > >>> >> wrote: > >>> >> > > >>> >> > > >>> >> > > >>> >> > 2013/4/10 Igor Stasenko <siguctua(a)gmail.com> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> On 10 April 2013 09:14, Tristan Bourgois > >>> >> >> <tristan.bourgois(a)gmail.com> > >>> >> >> wrote: > >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> 2013/4/9 Igor Stasenko <siguctua(a)gmail.com> > >>> >> >>>> > >>> >> >>>> Yes, this is a known bug actually, which i demonstrated to > >>> >> >>>> audience > >>> >> >>>> during > >>> >> >>>> tutorial presentation.. > >>> >> >>>> i/cairo miss the correct font matrix setup.. and i need to see > >>> >> >>>> what's > >>> >> >>>> there. > >>> >> >>>> Cairo caching the glyphs in a strange way (so if you never > drawn > >>> >> >>>> anything with given font before and your first drawing will use > >>> >> >>>> some > >>> >> >>>> rotation > >>> >> >>>> then everything will be rendered correctly, but if you already > >>> >> >>>> drawn > >>> >> >>>> anything > >>> >> >>>> it will render them like you shown).. > >>> >> >>>> I'm going to fix that issue when i come back from Lviv. > >>> >> >>>> > >>> >> >>> > >>> >> >>> Super :) > >>> >> >>> > >>> >> >>> Did you also see the cairo_text_path() method? It's very > >>> >> >>> interesting > >>> >> >>> if > >>> >> >>> you want to stroke the letter! > >>> >> >> > >>> >> >> > >>> >> >> Yes but this is more for fancy artistic text. For rendering large > >>> >> >> amounts > >>> >> >> of text (like big lists/source code) you don't want to do that, > >>> >> >> because it will be too slow. > >>> >> >> > >>> >> > > >>> >> > Thanks for the advice I will share it to my team because they want > >>> >> > performance and use text_path instead of show_text. > >>> >> > > >>> >> > >>> >> yes, the freetype library (and i guess you using it) is highly > >>> >> optimized for font rendering. > >>> >> sure thing, cairo path rendering is fast as well, but it is not as > >>> >> specialized for just font rendering as freetype, > >>> >> therefore, i have no doubts that it will be slower. > >>> >> > >>> >> > >>> > > >>> > > >>> > I only use Athens to rendering the graphics framework :) And I try to > >>> > not > >>> > use directly some AthensCairo object to benefit of futur new backend > of > >>> > Athens :) and sincerely you really make a good job of the Athens > >>> > interface! > >>> > It's very easy to use it! In one case I use AthensCairo object. I > have > >>> > to > >>> > use AthensCairoMatrix instead of AthensAffineTransform to represent > the > >>> > transformation of a shape because I have to make an inversion of the > >>> > matrix > >>> > to make a global position to the local position of the shape. > >>> > > >>> Ah, you mean this: > >>> > >>> AthensAffineTransform>>inverted > >>> "answer an inverse transformation of receiver" > >>> self notYetImplemented > >>> > >>> yes, someone has to implement it ;) > >>> > >> > >> If the weather is bad at Brest this week-end I will try to implement it > :) > >> (My last lesson of Matrix calculation is very old!) > >> > >>> But actually you can just use #inverseTransform: aPoint > >>> > >>> i.e. if: > >>> > >>> pt := m transform: somePoint. > >>> > >>> then > >>> > >>> somePoint closeTo: (m inverseTransform: pt) ==> true. > >>> > >>> (close to instead of #= because of float rounding errors) > >>> > >>> > >>> -- > >>> Best regards, > >>> Igor Stasenko. > >>> > >> > > > > > > -- > Best regards, > Igor Stasenko. > >

April 26, 2013