- Pharo-dev - lists.pharo.org

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

by GOUBIER Thierry

And you see things appearing in the wrong order inside, as well. Like the start of image line appearing after the new comment change :( Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Frank Shearar [frank.shearar(a)gmail.com] Date d'envoi : vendredi 26 avril 2013 10:33 Ã : Pharo Development Objet : Re: [Pharo-project] RE : cannot modify class comments on Linux Right. That would make the .changes file shorter than expected! frank On 26 April 2013 09: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: > > 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 >>>>> >>>>> >>>> >>> >> >

April 26, 2013

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

by Frank Shearar

Right. That would make the .changes file shorter than expected! frank On 26 April 2013 09: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: > > 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 >>>>> >>>>> >>>> >>> >> >

April 26, 2013

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

by GOUBIER Thierry

Yes, adding self flush solves the problem. 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 : vendredi 26 avril 2013 10:27 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : cannot modify class comments on Linux 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: Cheers, -- Pavel On Fri, Apr 26, 2013 at 9:57 AM, GOUBIER Thierry <thierry.goubier(a)cea.fr<mailto:thierry.goubier@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<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] de la part de Pavel Krivanek [pavel.krivanek(a)gmail.com<mailto:pavel.krivanek@gmail.com>] Date d'envoi : jeudi 25 avril 2013 21:32 Ã : Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:giseladecuzzi@gmail.com>> wrote: I'm on 64-bit Ubuntu 12.04 2013/4/25 Pavel Krivanek <pavel.krivanek(a)gmail.com<mailto:pavel.krivanek@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<mailto:giseladecuzzi@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<mailto:pavel.krivanek@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

April 26, 2013

Re: [Pharo-project] Smart Suggestion Version 1

by Gisela Decuzzi

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 Pavel Krivanek

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: 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 >>>>> >>>> >>>> >>> >> >

April 26, 2013

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

by GOUBIER Thierry

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<mailto:giseladecuzzi@gmail.com>> wrote: I'm on 64-bit Ubuntu 12.04 2013/4/25 Pavel Krivanek <pavel.krivanek(a)gmail.com<mailto:pavel.krivanek@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<mailto:giseladecuzzi@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<mailto:pavel.krivanek@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

April 26, 2013

Re: [Pharo-project] Call for ESUG 2013 presentations

by Damien Cassou

On Wed, Apr 24, 2013 at 7:05 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > I don't see that announcement on Squeak mailing list, nor others except > vwnc, on comp.lang.smalltalk should also go, also squeakland, etoys, ... a single person can not be on all mailing lists. StÃ©phane's email starts with "Please distribute as widely as possible", so it is quite clear that StÃ©phane wants everyone to help distribute the message. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

April 26, 2013

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

by Mariano Vicente

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,â 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. >> >> >

April 26, 2013

Re: [Pharo-project] [ANN] Sqnappy - a fast compressor wrapper

by Marcus Denker

I have put a new entry on http://pharo-project.org with this [ANN]. On Apr 26, 2013, at 4:51 AM, Masashi UMEZAWA <masashi.umezawa(a)gmail.com> wrote: > Hi all, > > Recently I've developed Sqnappy - Squeak/Pharo binding of the snappy > compressor library. > https://github.com/mumez/sqnappy > > About snappy: > https://code.google.com/p/snappy/ > > Sqnappy is easy to use. You can just send #compress:, #uncompress to SnappyCore: > compressed := SnappyCore compress: data. > uncompressed := SnappyCore uncompress: compressed. > > With a simple test, Sqnappy was 10.8x faster than the existing > GZipWriteStream/GZipReadStream. > > Additionally, Sqnappy implements snappy framing format, so that it can > treat big data with a small memory allocation. > > About framing format: > https://code.google.com/p/snappy/source/browse/trunk/framing_format.txt > > Tested from a workspace, 1.3 GB pg_dump file was compressed in around > 10 seconds and decompressed in 6.5 seconds . No annoying GCs. It was > comfortable. > > Enjoy! > -- > [:masashi | ^umezawa] >

April 26, 2013

Re: [Pharo-project] [ANN] Sqnappy - a fast compressor wrapper

by Marcus Denker

Very nice! We plan to (at some point) move to a one-image format (no source/changes, no need to explain that this .image file is indeed not a pictureâ¦). With this .pharo image we want to explore to ship the image compressed by default, so people don't need to put .zip files on the build server, for example. Snappy and lz4 are both interesting candidates for this. Marcus On Apr 26, 2013, at 4:51 AM, Masashi UMEZAWA <masashi.umezawa(a)gmail.com> wrote: > Hi all, > > Recently I've developed Sqnappy - Squeak/Pharo binding of the snappy > compressor library. > https://github.com/mumez/sqnappy > > About snappy: > https://code.google.com/p/snappy/ > > Sqnappy is easy to use. You can just send #compress:, #uncompress to SnappyCore: > compressed := SnappyCore compress: data. > uncompressed := SnappyCore uncompress: compressed. > > With a simple test, Sqnappy was 10.8x faster than the existing > GZipWriteStream/GZipReadStream. > > Additionally, Sqnappy implements snappy framing format, so that it can > treat big data with a small memory allocation. > > About framing format: > https://code.google.com/p/snappy/source/browse/trunk/framing_format.txt > > Tested from a workspace, 1.3 GB pg_dump file was compressed in around > 10 seconds and decompressed in 6.5 seconds . No annoying GCs. It was > comfortable. > > Enjoy! > -- > [:masashi | ^umezawa] >

April 26, 2013