May 2015 - Pharo-dev - lists.pharo.org

[SURVEY] Code Critics Usage

by Yuriy Tymchuk

Dear Pharo developers, I kindly ask you to participate in the Code Critics mini-survey: https://www.esurveycreator.com/s/8af18d8. It will take only a coupe minutes of your time (or less), and will give us the better understanding of how Code Critics are currently used and how to improve them. Cheers! Yuriy

May 4, 2015

Re: [Pharo-dev] Roassal3D and Woden process handling

by Yuriy Tymchuk

Sadly, Iâm not very experienced in that topic. I just looked at CodeCity running on my colleagueâs matching and syntax highlighting working. The view is also subclassing GLViewportMorph, but other than that I canât tell why CodeCity is not blocking the other processes. Uko > On 04 May 2015, at 16:47, phil(a)highoctane.be wrote: > > > > On Mon, May 4, 2015 at 4:16 PM, Ronie Salgado <roniesalg(a)gmail.com <mailto:roniesalg@gmail.com>> wrote: > Hi Yuriy, > > Process and OpenGL are a pain in the ass. This is why I hate the Smalltalk green threads, for the following reasons: > - Operating system Thread Local Storage is not respected. The current OpenGL is a thread local variable. > - No completely preemptive. > > Making Woden and Woden-Roassal to have a lower priority is a problem, because of reduced performance in Woden. When using OpenGL, the functions glFinish or SwapBuffers has to be called to force the execution of commands an display the rendered image in the screen. SwapBuffers usually calls glFlush. And if, v-sync is enabled, it blocks, which does not get well Pharo. > > With OSWindow, OpenGL can also be used to render the main Pharo window via SDL2. Because of this, I had to introduce a rendering process in OSWindow, which I am using to serialize all the OpenGL commands. And I guess that it also produces a reduction in performance. This thread is located OSWindowRenderThread. > > Perhaps you can fix the problem somewhere in OSWindowRenderThread. > > > Not having had a look, I suppose that this is a green thread in Pharo. > > Why not having a real OS thread doing the glFinish/SwapBuffers instead? > and some OpenGL ThreadLocal interface? > > > I am facing a kind of similar situation for another project. > > My current line of thought is that the best stable/fast thing is to have the 3D engine as a separate process (as in a true OS process) to which I do send high level commands. > > Of course, this makes it necessary to have a DSL to talk with and that extending the 3D engine is somewhat of a pain when in need of new commands. > > But it allows to do whatever I want in Pharo without blocking the rendering loop. > > What would be the design you'd like to see for Woden, Ronie? > > Phil > > > Best regards, > Ronie > > > 2015-05-04 11:36 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>>: > Hi! > > This is an excellent question. Ronie? > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On May 4, 2015, at 9:33 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> >> Hi guys, >> >> Iâm not experienced in OpenGL, but Iâve noticed that both Roassal3D and Woden occupy a high level process and are not yielding Processor to anyone else. For example code highlight, spotter, and other lower priority processes are not working as soon as you open a 3D visualization. On the other hand this doesnât happen while using CodeCity (and it also uses OpenGL). Is it very complicated to make Roassal3D and Woden to respect other processes? >> >> Uko > > > > > > -- > >

May 4, 2015

Re: [Pharo-dev] Roassal3D and Woden process handling

by phil＠highoctane.be

On Mon, May 4, 2015 at 4:16 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Hi Yuriy, > > Process and OpenGL are a pain in the ass. This is why I hate the Smalltalk > green threads, for the following reasons: > - Operating system Thread Local Storage is not respected. The current > OpenGL is a thread local variable. > - No completely preemptive. > > Making Woden and Woden-Roassal to have a lower priority is a problem, > because of reduced performance in Woden. When using OpenGL, the functions > glFinish or SwapBuffers has to be called to force the execution of commands > an display the rendered image in the screen. SwapBuffers usually calls > glFlush. And if, v-sync is enabled, it blocks, which does not get well > Pharo. > > With OSWindow, OpenGL can also be used to render the main Pharo window via > SDL2. Because of this, I had to introduce a rendering process in OSWindow, > which I am using to serialize all the OpenGL commands. And I guess that it > also produces a reduction in performance. This thread is located > OSWindowRenderThread. > > Perhaps you can fix the problem somewhere in OSWindowRenderThread. > Not having had a look, I suppose that this is a green thread in Pharo. Why not having a real OS thread doing the glFinish/SwapBuffers instead? and some OpenGL ThreadLocal interface? I am facing a kind of similar situation for another project. My current line of thought is that the best stable/fast thing is to have the 3D engine as a separate process (as in a true OS process) to which I do send high level commands. Of course, this makes it necessary to have a DSL to talk with and that extending the 3D engine is somewhat of a pain when in need of new commands. But it allows to do whatever I want in Pharo without blocking the rendering loop. What would be the design you'd like to see for Woden, Ronie? Phil > Best regards, > Ronie > > > 2015-05-04 11:36 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > >> Hi! >> >> This is an excellent question. Ronie? >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> On May 4, 2015, at 9:33 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Hi guys, >> >> Iâm not experienced in OpenGL, but Iâve noticed that both Roassal3D and >> Woden occupy a high level process and are not yielding Processor to anyone >> else. For example code highlight, spotter, and other lower priority >> processes are not working as soon as you open a 3D visualization. On the >> other hand this doesnât happen while using CodeCity (and it also uses >> OpenGL). Is it very complicated to make Roassal3D and Woden to respect >> other processes? >> >> Uko >> >> >> > --

May 4, 2015

Re: [Pharo-dev] Roassal3D and Woden process handling

by Alexandre Bergel

Hi! This is an excellent question. Ronie? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On May 4, 2015, at 9:33 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi guys, > > Iâm not experienced in OpenGL, but Iâve noticed that both Roassal3D and Woden occupy a high level process and are not yielding Processor to anyone else. For example code highlight, spotter, and other lower priority processes are not working as soon as you open a 3D visualization. On the other hand this doesnât happen while using CodeCity (and it also uses OpenGL). Is it very complicated to make Roassal3D and Woden to respect other processes? > > Uko

May 4, 2015

Re: [Pharo-dev] Main pillar web site?

by Cyril Ferlicot

Hi. The documentation is now here: https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… We're still updating the documentation so that still can change. On 4 May 2015 at 16:14, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > Thank you! > > Here is the summary > > > > Pillar documentation > ==================== > > Start page > http://www.smalltalkhub.com/#!/~Pier/Pillar > > > Documentation > https://github.com/pillar-markup/pillar-documentation > > > > First Google hit > https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/… > > Leads to Pharo contribution CI server (Confirm security exception, it is safe). > > > > Pillar tool chain repositories > ------------------------------- > > https://github.com/pillar-markup > -- Cheers Cyril Ferlicot

May 4, 2015

Re: [Pharo-dev] MC: Strange Problem

by Nicolai Hess

2015-05-04 16:04 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > > 2015-05-04 16:01 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > >> >> >> 2015-05-04 15:40 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >> >>> >>> >>> On Mon, May 4, 2015 at 9:27 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> >>>> >>>> >>>> 2015-05-04 15:09 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >>>> >>>>> >>>>> >>>>> 2015-05-04 14:58 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >>>>> >>>>>> >>>>>> >>>>>> 2015-05-04 14:35 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com >>>>>> >: >>>>>> >>>>>>> Ok, I had a look on >>>>>>> >>>>>>> ConfigurationOfTxText-SeanDeNigris.48 >>>>>>> >>>>>>> And, what I can see: >>>>>>> >>>>>>> - two rpackages are created upon loading: 'ConfigurationOfTxText' >>>>>>> and 'a MCWorkingCopy(ConfigurationOfTxText)'. >>>>>>> >>>>>>> - Two WorkingCopy(s) are created, but one is NicolaiHess.42 (the one >>>>>>> already in the image in Pharo 4). >>>>>>> >>>>>>> - History stops at NicolaiHess.42 ? >>>>>>> >>>>>> >>>>>> Ups! >>>>>> >>>>> >>>>> The thing is, ConfigurationOfTxText-NicolaiHess.42 which is in >>>>> Pharo40Inbox is fine and has the full history :) >>>>> >>>>> But, ConfigurationOfTxText-NicolaiHess.43 in TxText has its history >>>>> cut at NicolaiHess.42 :( >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> All packages newer than NicolaiHess.42 have their history cut at >>>>>>> NicolaiHess.42. And a few (SeanDeNigris.48 for sure) have 'a >>>>>>> MCWorkingCopy(ConfigurationOfTxText)' as package name instead of >>>>>>> 'ConfigurationOfTxText', and this is inside the .mcz. >>>>>>> >>>>>>> How where those packages saved? >>>>>>> >>>>>> >>>>>> Don't know what I did wrong, but I don't know much about this and >>>>>> don't have much experience with this. >>>>>> I just copied the packages from the repository to the inbox when I >>>>>> created a new configuration. >>>>>> >>>>> >>>>> I haven't checked on the packages themselves, I'm just looking at the >>>>> ConfigurationOfTxText for the moment... >>>>> >>>>> Something strange happened when .43 was created. And, yes, it's a bit >>>>> strange: each time the configuration is saved in Pharo40Inbox, it is not >>>>> present in the TxText repository (except when it's Esteban, Stef or >>>>> Igor...). Are you sure you have used 'Copy' and not saved a new version in >>>>> the Pharo40Inbox? >>>>> >>>> >>>> No, I am sure I did *not* use copy! >>>> The first time I tried to create a ConfigurationOfXXX (I think it was >>>> for Athens) I said I cannot "copy" to inbox and ask how copying to the >>>> inbox works. >>>> >>> >>> Is this what you experience? (sorry I hadn't got to try fixing it yet) >>> https://pharo.fogbugz.com/default.asp?11833 "Monticello >>> Repository-view <Copy> button does not ask for access credentials" >>> cheers -ben >>> >> >> Looks like. I nearly always work with throw away images where my >> credentials aren't set on image startup. >> Saving to a repository works, because it asks for user/password. >> > > In fact, this bug only happens if your username isn't set for the target > of the copy. > > If you edit the repository info before, setting just your username, the > copy operation will ask you your password. > > I have been doing that for ages... > Ah. Ok, sorry for that. I didn't know this was the wrong way. > > Thierry > > >> >> >> >> >>> >>> >>>> And I was told "to save" the Configuration to the inbox. >>>> >>>> I think I always saved a new version instead of copying. >>>> How can other people copy instead of save ? I always got an error on >>>> "copy". >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Thierry >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Thierry >>>>>>> >>>>>>> >>>>>>> 2015-05-04 12:58 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>>>>> >>>>>>>> Thierry Goubier wrote >>>>>>>> > can you point me towards one of those corrupt versions? >>>>>>>> >>>>>>>> Apparently the problem started with >>>>>>>> ConfigurationOfTxText-SeanDeNigris.48 >>>>>>>> and then ConfigurationOfTxText-SeanDeNigris.49 in >>>>>>>> http://smalltalkhub.com/mc/Pharo/TxText/main/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ----- >>>>>>>> Cheers, >>>>>>>> Sean >>>>>>>> -- >>>>>>>> View this message in context: >>>>>>>> http://forum.world.st/MC-Strange-Problem-tp4824138p4824212.html >>>>>>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>>>>> Nabble.com. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >

May 4, 2015

Re: [Pharo-dev] Roassal3D and Woden process handling

by Ronie Salgado

Hi Yuriy, Process and OpenGL are a pain in the ass. This is why I hate the Smalltalk green threads, for the following reasons: - Operating system Thread Local Storage is not respected. The current OpenGL is a thread local variable. - No completely preemptive. Making Woden and Woden-Roassal to have a lower priority is a problem, because of reduced performance in Woden. When using OpenGL, the functions glFinish or SwapBuffers has to be called to force the execution of commands an display the rendered image in the screen. SwapBuffers usually calls glFlush. And if, v-sync is enabled, it blocks, which does not get well Pharo. With OSWindow, OpenGL can also be used to render the main Pharo window via SDL2. Because of this, I had to introduce a rendering process in OSWindow, which I am using to serialize all the OpenGL commands. And I guess that it also produces a reduction in performance. This thread is located OSWindowRenderThread. Perhaps you can fix the problem somewhere in OSWindowRenderThread. Best regards, Ronie 2015-05-04 11:36 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Hi! > > This is an excellent question. Ronie? > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On May 4, 2015, at 9:33 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi guys, > > Iâm not experienced in OpenGL, but Iâve noticed that both Roassal3D and > Woden occupy a high level process and are not yielding Processor to anyone > else. For example code highlight, spotter, and other lower priority > processes are not working as soon as you open a 3D visualization. On the > other hand this doesnât happen while using CodeCity (and it also uses > OpenGL). Is it very complicated to make Roassal3D and Woden to respect > other processes? > > Uko > > >

May 4, 2015

Re: [Pharo-dev] Main pillar web site?

by H. Hirzel

Thank you! Here is the summary Pillar documentation ==================== Start page http://www.smalltalkhub.com/#!/~Pier/Pillar Documentation https://github.com/pillar-markup/pillar-documentation First Google hit https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/… Leads to Pharo contribution CI server (Confirm security exception, it is safe). Pillar tool chain repositories ------------------------------- https://github.com/pillar-markup

May 4, 2015

Re: [Pharo-dev] MC: Strange Problem

by Thierry Goubier

2015-05-04 16:01 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-05-04 15:40 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > >> >> >> On Mon, May 4, 2015 at 9:27 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> >>> >>> 2015-05-04 15:09 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >>> >>>> >>>> >>>> 2015-05-04 14:58 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >>>> >>>>> >>>>> >>>>> 2015-05-04 14:35 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com> >>>>> : >>>>> >>>>>> Ok, I had a look on >>>>>> >>>>>> ConfigurationOfTxText-SeanDeNigris.48 >>>>>> >>>>>> And, what I can see: >>>>>> >>>>>> - two rpackages are created upon loading: 'ConfigurationOfTxText' and >>>>>> 'a MCWorkingCopy(ConfigurationOfTxText)'. >>>>>> >>>>>> - Two WorkingCopy(s) are created, but one is NicolaiHess.42 (the one >>>>>> already in the image in Pharo 4). >>>>>> >>>>>> - History stops at NicolaiHess.42 ? >>>>>> >>>>> >>>>> Ups! >>>>> >>>> >>>> The thing is, ConfigurationOfTxText-NicolaiHess.42 which is in >>>> Pharo40Inbox is fine and has the full history :) >>>> >>>> But, ConfigurationOfTxText-NicolaiHess.43 in TxText has its history cut >>>> at NicolaiHess.42 :( >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> All packages newer than NicolaiHess.42 have their history cut at >>>>>> NicolaiHess.42. And a few (SeanDeNigris.48 for sure) have 'a >>>>>> MCWorkingCopy(ConfigurationOfTxText)' as package name instead of >>>>>> 'ConfigurationOfTxText', and this is inside the .mcz. >>>>>> >>>>>> How where those packages saved? >>>>>> >>>>> >>>>> Don't know what I did wrong, but I don't know much about this and >>>>> don't have much experience with this. >>>>> I just copied the packages from the repository to the inbox when I >>>>> created a new configuration. >>>>> >>>> >>>> I haven't checked on the packages themselves, I'm just looking at the >>>> ConfigurationOfTxText for the moment... >>>> >>>> Something strange happened when .43 was created. And, yes, it's a bit >>>> strange: each time the configuration is saved in Pharo40Inbox, it is not >>>> present in the TxText repository (except when it's Esteban, Stef or >>>> Igor...). Are you sure you have used 'Copy' and not saved a new version in >>>> the Pharo40Inbox? >>>> >>> >>> No, I am sure I did *not* use copy! >>> The first time I tried to create a ConfigurationOfXXX (I think it was >>> for Athens) I said I cannot "copy" to inbox and ask how copying to the >>> inbox works. >>> >> >> Is this what you experience? (sorry I hadn't got to try fixing it yet) >> https://pharo.fogbugz.com/default.asp?11833 "Monticello >> Repository-view <Copy> button does not ask for access credentials" >> cheers -ben >> > > Looks like. I nearly always work with throw away images where my > credentials aren't set on image startup. > Saving to a repository works, because it asks for user/password. > In fact, this bug only happens if your username isn't set for the target of the copy. If you edit the repository info before, setting just your username, the copy operation will ask you your password. I have been doing that for ages... Thierry > > > > >> >> >>> And I was told "to save" the Configuration to the inbox. >>> >>> I think I always saved a new version instead of copying. >>> How can other people copy instead of save ? I always got an error on >>> "copy". >>> >>> >>> >>> >>> >>>> >>>> Thierry >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Thierry >>>>>> >>>>>> >>>>>> 2015-05-04 12:58 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>>>> >>>>>>> Thierry Goubier wrote >>>>>>> > can you point me towards one of those corrupt versions? >>>>>>> >>>>>>> Apparently the problem started with >>>>>>> ConfigurationOfTxText-SeanDeNigris.48 >>>>>>> and then ConfigurationOfTxText-SeanDeNigris.49 in >>>>>>> http://smalltalkhub.com/mc/Pharo/TxText/main/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- >>>>>>> Cheers, >>>>>>> Sean >>>>>>> -- >>>>>>> View this message in context: >>>>>>> http://forum.world.st/MC-Strange-Problem-tp4824138p4824212.html >>>>>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>>>> Nabble.com. >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >

May 4, 2015

Re: [Pharo-dev] MC: Strange Problem

by Nicolai Hess

2015-05-04 15:40 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > > > On Mon, May 4, 2015 at 9:27 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> >> 2015-05-04 15:09 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> >>> >>> >>> 2015-05-04 14:58 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >>> >>>> >>>> >>>> 2015-05-04 14:35 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >>>> >>>>> Ok, I had a look on >>>>> >>>>> ConfigurationOfTxText-SeanDeNigris.48 >>>>> >>>>> And, what I can see: >>>>> >>>>> - two rpackages are created upon loading: 'ConfigurationOfTxText' and >>>>> 'a MCWorkingCopy(ConfigurationOfTxText)'. >>>>> >>>>> - Two WorkingCopy(s) are created, but one is NicolaiHess.42 (the one >>>>> already in the image in Pharo 4). >>>>> >>>>> - History stops at NicolaiHess.42 ? >>>>> >>>> >>>> Ups! >>>> >>> >>> The thing is, ConfigurationOfTxText-NicolaiHess.42 which is in >>> Pharo40Inbox is fine and has the full history :) >>> >>> But, ConfigurationOfTxText-NicolaiHess.43 in TxText has its history cut >>> at NicolaiHess.42 :( >>> >>> >>>> >>>> >>>>> >>>>> All packages newer than NicolaiHess.42 have their history cut at >>>>> NicolaiHess.42. And a few (SeanDeNigris.48 for sure) have 'a >>>>> MCWorkingCopy(ConfigurationOfTxText)' as package name instead of >>>>> 'ConfigurationOfTxText', and this is inside the .mcz. >>>>> >>>>> How where those packages saved? >>>>> >>>> >>>> Don't know what I did wrong, but I don't know much about this and don't >>>> have much experience with this. >>>> I just copied the packages from the repository to the inbox when I >>>> created a new configuration. >>>> >>> >>> I haven't checked on the packages themselves, I'm just looking at the >>> ConfigurationOfTxText for the moment... >>> >>> Something strange happened when .43 was created. And, yes, it's a bit >>> strange: each time the configuration is saved in Pharo40Inbox, it is not >>> present in the TxText repository (except when it's Esteban, Stef or >>> Igor...). Are you sure you have used 'Copy' and not saved a new version in >>> the Pharo40Inbox? >>> >> >> No, I am sure I did *not* use copy! >> The first time I tried to create a ConfigurationOfXXX (I think it was for >> Athens) I said I cannot "copy" to inbox and ask how copying to the inbox >> works. >> > > Is this what you experience? (sorry I hadn't got to try fixing it yet) > https://pharo.fogbugz.com/default.asp?11833 "Monticello > Repository-view <Copy> button does not ask for access credentials" > cheers -ben > Looks like. I nearly always work with throw away images where my credentials aren't set on image startup. Saving to a repository works, because it asks for user/password. > > >> And I was told "to save" the Configuration to the inbox. >> >> I think I always saved a new version instead of copying. >> How can other people copy instead of save ? I always got an error on >> "copy". >> >> >> >> >> >>> >>> Thierry >>> >>> >>> >>>> >>>> >>>> >>>> >>>>> >>>>> Thierry >>>>> >>>>> >>>>> 2015-05-04 12:58 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>>> >>>>>> Thierry Goubier wrote >>>>>> > can you point me towards one of those corrupt versions? >>>>>> >>>>>> Apparently the problem started with >>>>>> ConfigurationOfTxText-SeanDeNigris.48 >>>>>> and then ConfigurationOfTxText-SeanDeNigris.49 in >>>>>> http://smalltalkhub.com/mc/Pharo/TxText/main/ >>>>>> >>>>>> >>>>>> >>>>>> ----- >>>>>> Cheers, >>>>>> Sean >>>>>> -- >>>>>> View this message in context: >>>>>> http://forum.world.st/MC-Strange-Problem-tp4824138p4824212.html >>>>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>>> Nabble.com. >>>>>> >>>>>> >>>>> >>>> >>> >> >

May 4, 2015