- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] why so many processes are running at startup time?

by NISHIHARA Satoshi

Caekenberghe san 11 lines of code in previous e-mail, extracted from SmalltalkImage>> privCleanProcesses (20607 image), and modified. Browser fullOnClass: SmalltalkImage selector: #privCleanProcesses. or Nautilus fullOnClass: SmalltalkImage selector: #privCleanProcesses. please use freely. regards. 2013/6/21 Sven Van Caekenberghe <sven(a)stfx.eu> > Hi Satoshi, > > On 20 Jun 2013, at 12:18, NISHIHARA Satoshi <goonsh(a)gmail.com> wrote: > > > thx. > > > > I run a cleaning processes script such as: > > (Process allInstances > > reject: [ :p | > > {(InputEventFetcher default fetcherProcess). > > (Processor activeProcess). > > (WeakArray runningFinalizationProcess). > > (Processor backgroundProcess). > > (SmalltalkImage current lowSpaceWatcherProcess). > > (UIManager default uiProcess). > > (Delay schedulingProcess)} includes: p ]) > > do: [ :p | > > p suspend; terminate ] > > This code looks like a nice start for writing a unit test that could > verify that there are no bogus processes in delivered images. > > We already have a number of tests that do global quality checks (like > Undeclared, bogus instances, ..), we need this as well. > > Any opinions, comments ? > > Sven > > > and get 6 processes remain: > > (80) 745275392: Delay class>>handleTimerEvent > > (60) Input events fetching process: InputEventFetcher>>waitForInput > > (60) 1061945344: SmalltalkImage>>lowSpaceWatcher > > (50) 946339840: WeakArray class>>finalizationProcess > > (40s) Morphic UI process: nil > > (10) 845938688: ProcessorScheduler class>>idleProcess > > > > is this OK? > > > > regards. > > > > > > 2013/6/20 Marcus Denker <marcus.denker(a)inria.fr> > > Hi, > > > > I think we should for now just kill them when building the image, I will > check. > > > > On Jun 20, 2013, at 9:56 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > > > >> Hello, > >> > >> These processes are due to the new integration testing process. This > new process was introduced in Pharo 3.0 alpha, and we found the bug and > fixed it. > >> Recently we backport the new integration process to Pharo 2.0 and > seemingly it created the same bug but since we read your mail we were not > aware of it. We need to backport the fix. > >> We will fix that within a few days. > >> > >> As a workaround, you can just kill these processes in your image for > now ... > >> > >> Thanks for reporting the issue, > >> > >> > >> > >> > >> 2013/6/20 NISHIHARA Satoshi <goonsh(a)gmail.com> > >> There are 30 over processes are running at startup, Pharo-20607.image. > >> > >> <NDOWS-1252?B?vIgyMDEzLTA2LTIwIDEzLjE5LjU277yJLnBuZw=.png> > >> > >> regards. > >> > >> -- > >> -- > >> "NISHIHARA Satoshi" > >> [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] > >> > >> > >> > >> -- > >> ClÃ©ment BÃ©ra > >> Mate Virtual Machine Engineer > >> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > > > > > > > > > -- > > -- > > "NISHIHARA Satoshi" > > [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] > > > -- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]

June 20, 2013

Re: [Pharo-dev] you may need to update your configurations

by StÃ©phane Ducasse

On Jun 19, 2013, at 11:03 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Certainly not in 2.0 > Even in 3.0, this will be hard because this mean a big clean-up of Stream mess (Xtreams?) I would love that. Any progress in that direction is welcome. > > > 2013/6/19 Sven Van Caekenberghe <sven(a)stfx.eu> > > On 19 Jun 2013, at 22:55, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > Yes, this part is perfectly correct. > > It's just that I used ZnInvalidUTF8 in TextConverter which introduces a dependency of TextConverter on Zinc. > > OK, but technically, it is a dependency on Zinc-Character-Encoding-Core, which is independent of the Zinc HTTP code itself. Just like Zinc-Resource-Meta-Core (containing ZnUrl and ZnMimeType) is independent of the HTTP code proper. These sub packages where created specifically to break unwanted dependencies, as requested by Pavel et al. > > > This only make sense if in the long term we replace those TextConverters by cleaner Zinc encoders/decoders. > > Yes, that is the idea, eventually. But never in 2.0. > > > 2013/6/19 Sven Van Caekenberghe <sven(a)stfx.eu> > > > > On 19 Jun 2013, at 22:33, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > > The change is very light, I applied it almost unchanged on Squeak (can't remember which version was the first). > > > The only thing we neeed is to catch an UTF8Error. > > > > > > Since in Pharo there are two encoder/decoder hierarchies, and since that of Zinc is cleaner, I made a bet on future and chose to make UTF8Error a subclass of existing already Zn Encoding/Decoding exception. > > > > > > But we still use the old TextConverter hierarchy in MC, even in Pharo 3.0. > > > So the dependency on Zinc is totally arbitrary and un-necessary right now; it does not exist in Smalltalk version. > > > It's just a bet on the future. > > > For a backport to 2.0, I would just use an UTF8Error like in Squeak and avoid any dependency on Zinc. > > > > Well ZnInvalidUTF8 is now a full part of Zinc itself (Zinc-Character-Encoding-Core to be exact). It is already in 3.0 (with your code) and I guess we'll upgrade Zinc in 2.0 as well. But is is a dependency, that is correct. > > > > Anyway, we have to double check. > > > > > Nicolas > > > > > > > > > 2013/6/19 GOUBIER Thierry <thierry.goubier(a)cea.fr> > > > StÃ©phane, > > > > > > I'll probably have a look at Nicolas fix anyway, but as it required also a change to Zinc... then I started to worry. But it may be better than trying to fix ZipArchive incorrect encoding issues from the outside (by forcing an utf8 conversion out of the contents of the ZipArchive members). > > > > > > If I manage to make sense of it, I'll put a enhancement request in FogBuz with a slice. > > > > > > Yes, I think 30 is not that unstable, like 2.0 was before ... except that I'm fairly dependent on the RPackage infrastructure, and I prefer to wait until the RPackage refactoring is done ;-) > > > > > > Thierry > > > > > > ________________________________________ > > > De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > > > Date d'envoi : mercredi 19 juin 2013 21:21 > > > Ã : Pharo Development List > > > Objet : Re: [Pharo-dev] you may need to update your configurations > > > > > > > > > > > > > > >> Christophe. > > > >> > > > >> [1] https://pharo.fogbugz.com/default.asp?10801 > > > > > > > > Ouch. Does not bode too well for backporting that to Pharo 2.0. > > > > > > > > I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so or fighting every few days with 3.0 and knowing that anyway it's not production ready. I had to cope with 1.4 not being able to handle utf8 in the same way. > > > > > > Thierry what we can do is the following: > > > have a look at the fix of nicolas and we can try to add to th 2.0 batch but we should pay attention > > > not to introduce other bugs (because I'm afraid it will). > > > > > > BTW 30 is not that instable. > > > > > > > > > > The window for my next serious developpement with Pharo is around 2014, so I guess I could just sit and wait. > > > > > > > > By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ? > > > > > > > > > > > > > > > > > >

June 20, 2013

Re: [Pharo-dev] Barcode

by StÃ©phane Ducasse

On Jun 20, 2013, at 5:21 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Stephan Eggermon wrote: >> So, this kind-of works. Both Artefact and Barcode repositories are not writable, >> so here is an artefact package that depends on barcode. > > Yes - the dependency should be Artefact requires barcode and then the code > could be integrated into Artefact. Why you can have another package ArteBar that depends on Artefact and BarCode. > > Note that there is no "writeable" repo in SmalltalkHub compared to SqS. > I can add you as a contributor to "Barcode" if you want to help with the code. > AFAIK soon SmalltalkHub will have inboxes... > > Maybe someone (Olivier) can also add me and Stephan to Artefact as > contributor. > > Thx > T. > > > > > > > > > > > >

June 20, 2013

Re: [Pharo-dev] taking a custom screenshot of a submorph

by Tudor Girba

One could, but it is not the same. The inspector offers a quick visual interface that allows you to browse a complex morph hierarchy. Taking the screenshot is secondary, but when combined with the visual feedback it gets more interesting. Cheers, Doru On Sun, Jun 9, 2013 at 7:21 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > One could use the halo, seems faster to me > > Ben > > On Jun 6, 2013, at 11:04 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Just in case you want to take a screenshot of a submorph, here is a > description + video of how you can do it using the GTInspector: > > > http://www.humane-assessment.com/blog/custom-morph-screenshot-with-gtinspec… > > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

June 20, 2013

Re: [Pharo-dev] why so many processes are running at startup time?

by Sven Van Caekenberghe

Hi Satoshi, On 20 Jun 2013, at 12:18, NISHIHARA Satoshi <goonsh(a)gmail.com> wrote: > thx. > > I run a cleaning processes script such as: > (Process allInstances > reject: [ :p | > {(InputEventFetcher default fetcherProcess). > (Processor activeProcess). > (WeakArray runningFinalizationProcess). > (Processor backgroundProcess). > (SmalltalkImage current lowSpaceWatcherProcess). > (UIManager default uiProcess). > (Delay schedulingProcess)} includes: p ]) > do: [ :p | > p suspend; terminate ] This code looks like a nice start for writing a unit test that could verify that there are no bogus processes in delivered images. We already have a number of tests that do global quality checks (like Undeclared, bogus instances, ..), we need this as well. Any opinions, comments ? Sven > and get 6 processes remain: > (80) 745275392: Delay class>>handleTimerEvent > (60) Input events fetching process: InputEventFetcher>>waitForInput > (60) 1061945344: SmalltalkImage>>lowSpaceWatcher > (50) 946339840: WeakArray class>>finalizationProcess > (40s) Morphic UI process: nil > (10) 845938688: ProcessorScheduler class>>idleProcess > > is this OK? > > regards. > > > 2013/6/20 Marcus Denker <marcus.denker(a)inria.fr> > Hi, > > I think we should for now just kill them when building the image, I will check. > > On Jun 20, 2013, at 9:56 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> Hello, >> >> These processes are due to the new integration testing process. This new process was introduced in Pharo 3.0 alpha, and we found the bug and fixed it. >> Recently we backport the new integration process to Pharo 2.0 and seemingly it created the same bug but since we read your mail we were not aware of it. We need to backport the fix. >> We will fix that within a few days. >> >> As a workaround, you can just kill these processes in your image for now ... >> >> Thanks for reporting the issue, >> >> >> >> >> 2013/6/20 NISHIHARA Satoshi <goonsh(a)gmail.com> >> There are 30 over processes are running at startup, Pharo-20607.image. >> >> <NDOWS-1252?B?vIgyMDEzLTA2LTIwIDEzLjE5LjU277yJLnBuZw=.png> >> >> regards. >> >> -- >> -- >> "NISHIHARA Satoshi" >> [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] >> >> >> >> -- >> ClÃ©ment BÃ©ra >> Mate Virtual Machine Engineer >> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > > > > -- > -- > "NISHIHARA Satoshi" > [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]

June 20, 2013

Barcode

by Torsten Bergmann

Stephan Eggermon wrote: >So, this kind-of works. Both Artefact and Barcode repositories are not writable, >so here is an artefact package that depends on barcode. Yes - the dependency should be Artefact requires barcode and then the code could be integrated into Artefact. Note that there is no "writeable" repo in SmalltalkHub compared to SqS. I can add you as a contributor to "Barcode" if you want to help with the code. AFAIK soon SmalltalkHub will have inboxes... Maybe someone (Olivier) can also add me and Stephan to Artefact as contributor. Thx T.

June 20, 2013

Re: [Pharo-dev] Cloud Hosting Tip

by Paul DeBruicker

kilon wrote > whats your opinion on linenode ? -> > https://www.linode.com <https://www.linode.com> > > Its what I currently use and it was recommended by a friend whos a web > developer. Its very nice service, but 200 euros per year is too much for > my needs. > > All I need is some space , the ability to run pharo and display a basic > website. So I might move to what you recommended here. 50 euros per year > seems a lot closer to my budget. If you're looking for cheap this hosting provider aggregator usually has coupons for lots of places: http://serverbear.com/ -- View this message in context: http://forum.world.st/Pharo-dev-Cloud-Hosting-Tip-tp4693950p4694293.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 20, 2013

Re: [Pharo-dev] Barcodes

by Olivier Auverlot

Hi Gary, Thanks for this informations. It's very interesting. > All the data there can be gatherted from the FreeType TTF font in Pharo. Just needs to be present on the end-user's pc. Have you already wrote code to extract the informations from a TTF font ? If someone has exploring this domain, we could write faster the implementation. Best regards Olivier ;-) Le 19 juin 2013 Ã 18:05, Gary Chambers a Ã©crit : > Hi Olivier. > > For our label/report generation we do draw the barcodes rather than use a Form. Actually we have a Canvas that adapts to generate PDF so it is all WYSIWYG. Therefore no actual dependency in the PDF generation to any barcode objects. > > Looking to support Arefact instead of the stuff we have. Not looked at the details of Artefact yet though. > > TTF in PDF is not so bad... a snippet of what's expected in the output: > > 6 0 obj > << > /Type /Font > /Subtype /TrueType > /BaseFont /Arial > /FirstChar 0 > /LastChar 255 > /Widths 8 0 R > /FontDescriptor 9 0 R > /Encoding /WinAnsiEncoding > >> > endobj > 9 0 obj > << > /Type /FontDescriptor > /FontName /Arial > /Flags 32 > /FontBBox [-665 -325 2000 1005] > /Ascent 905 > /Descent -212 > /Leading 0 > /ItalicAngle 0 > >> > endobj > 8 0 obj > [ 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 277 277 354 556 556 889 666 190 333 333 389 583 277 333 277 277 556 556 556 556 556 556 556 556 556 556 277 277 583 583 583 556 1015 666 666 722 722 666 610 777 722 277 500 666 556 833 722 777 666 777 722 666 610 722 666 943 666 666 610 277 277 277 469 556 333 556 556 500 556 556 277 556 556 222 222 500 222 833 556 556 556 556 333 500 277 556 500 722 500 500 500 333 259 333 583 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 750 277 333 556 556 556 556 259 556 333 736 370 556 583 333 736 552 399 548 333 333 333 576 537 333 333 333 365 556 833 833 833 610 666 666 666 666 666 666 1000 722 666 666 666 666 277 277 277 277 722 722 777 777 777 777 777 583 777 722 722 722 722 666 666 610 556 556 556 556 556 556 889 500 556 556 556 556 277 277 277 277 556 556 556 556 556 556 556 548 610 556 556 556 556 500 556 500 ] > endobj > > > (actually we now use MacRoman encoding as generally works better). > All the data there can be gatherted from the FreeType TTF font in Pharo. Just needs to be present on the end-user's pc. > A typical PDF reader will do fallbacks as necessary if not present. > (not tackled fully embedded fonts yet). > > Regards, Gary > ----- Original Message ----- > From: Olivier Auverlot > To: Pharo Development List > Sent: Wednesday, June 19, 2013 6:42 AM > Subject: Re: [Pharo-dev] Barcodes > > Hi Gary, > > yes, I'm interested by help and pointers about TTF. It's a planned evolution of Artefact. > > About barcodes generation, why don't use Artefact directly ? You can draw barcodes with the PDFDraw elements (PDFLineElement, PDFRectElement, etc.) and print the document on stickers. > > In the future, it could be cool to have a Artefact-Elements-Barcodes package :) > > Best regards > Olivier > > Le 18 juin 2013 Ã 18:37, Gary Chambers a Ã©crit : > >> Well, hoping to work with Torsten on barcodes in general, given we have support for canvas based drawing of a few formats here at Pinesoft. >> >> Also, if Olivier would like some help with TTF in PDFs I can give some pointers etc. >> >> Regards, Gary >> ----- Original Message ----- >> From: Chris Cunningham >> To: Pharo Development List >> Sent: Tuesday, June 18, 2013 5:23 PM >> Subject: Re: [Pharo-dev] Barcodes >> >> You should be able to create a form, paint it white, draw on it with a barcode TTF font, export that form to JPEG, and then use that JPEG into Artefact. >> >> Not really straight-forward, but it should work. >> >> *Note: I've found that writing JPEG's in Pharo, it assumes that the background is BLACK if it isn't isn't specifically painted with something else first. Unlike PNG and GIF, which assume WHITE. >> >> -Chris >> >> >> On Tue, Jun 18, 2013 at 1:44 AM, Olivier Auverlot <olivier.auverlot(a)gmail.com> wrote: >> Hi Torsten, >> >> Artefact don't support TTF fonts for the moment but it's planned in futures versions. >> >> Best regards >> Olivier :-) >> >> Le 14 juin 2013 Ã 16:16, Milan Mimica a Ã©crit : >> >>> You just need a TTF font. Does Artefact support TTF? hpdf does. >>> >>> >>> On 14 June 2013 13:58, Torsten Bergmann <astares(a)gmx.de> wrote: >>> Do we have some barcode stuff available for Pharo? >>> Something "Form" based that can be used with Artefact? >>> >>> Thx >>> T. >>> >>> >>> >>> >>> -- >>> Milan Mimica >>> http://sparklet.sf.net

June 20, 2013

Re: [Pharo-dev] [PROVENANCE INTERNET] Re: you may need to update your configurations

by Goubier Thierry

Done, https://pharo.fogbugz.com/f/cases/10978/Backport-20-ZipArchive-utf8-handling Thierry Le 20/06/2013 15:11, Goubier Thierry a Ã©crit : > Hi Nicholas, > > I think I'll backport your ZipArchiveMember>>contentStreamFromEncoding: > and I also have to backport UTF8TextConverter>>errorMalformedInput as well. > > It will solve my encoding problem on git archive loading. Nice. > > Thierry > > Le 19/06/2013 22:33, Nicolas Cellier a Ã©crit : >> The change is very light, I applied it almost unchanged on Squeak (can't >> remember which version was the first). >> The only thing we neeed is to catch an UTF8Error. >> >> Since in Pharo there are two encoder/decoder hierarchies, and since that >> of Zinc is cleaner, I made a bet on future and chose to make UTF8Error a >> subclass of existing already Zn Encoding/Decoding exception. >> >> But we still use the old TextConverter hierarchy in MC, even in Pharo >> 3.0. >> So the dependency on Zinc is totally arbitrary and un-necessary right >> now; it does not exist in Smalltalk version. >> It's just a bet on the future. >> For a backport to 2.0, I would just use an UTF8Error like in Squeak and >> avoid any dependency on Zinc. >> >> Nicolas >> >> >> 2013/6/19 GOUBIER Thierry <thierry.goubier(a)cea.fr >> <mailto:thierry.goubier@cea.fr>> >> >> StÃ©phane, >> >> I'll probably have a look at Nicolas fix anyway, but as it required >> also a change to Zinc... then I started to worry. But it may be >> better than trying to fix ZipArchive incorrect encoding issues from >> the outside (by forcing an utf8 conversion out of the contents of >> the ZipArchive members). >> >> If I manage to make sense of it, I'll put a enhancement request in >> FogBuz with a slice. >> >> Yes, I think 30 is not that unstable, like 2.0 was before ... except >> that I'm fairly dependent on the RPackage infrastructure, and I >> prefer to wait until the RPackage refactoring is done ;-) >> >> Thierry >> >> ________________________________________ >> De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org >> <mailto:pharo-dev-bounces@lists.pharo.org>] de la part de StÃ©phane >> Ducasse [stephane.ducasse(a)inria.fr >> <mailto:stephane.ducasse@inria.fr>] >> Date d'envoi : mercredi 19 juin 2013 21:21 >> Ã : Pharo Development List >> Objet : Re: [Pharo-dev] you may need to update your configurations >> >> > >> > >> >> Christophe. >> >> >> >> [1] https://pharo.fogbugz.com/default.asp?10801 >> > >> > Ouch. Does not bode too well for backporting that to Pharo 2.0. >> > >> > I'm feeling a bit down. It's either enduring bugs in 2.0 for a >> year or so or fighting every few days with 3.0 and knowing that >> anyway it's not production ready. I had to cope with 1.4 not being >> able to handle utf8 in the same way. >> >> Thierry what we can do is the following: >> have a look at the fix of nicolas and we can try to add to >> th 2.0 batch but we should pay attention >> not to introduce other bugs (because I'm afraid it will). >> >> BTW 30 is not that instable. >> >> >> > The window for my next serious developpement with Pharo is around >> 2014, so I guess I could just sit and wait. >> > >> > By the way, why the change in >> MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ? >> >> >> > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 20, 2013

Re: [Pharo-dev] you may need to update your configurations

by Goubier Thierry

Hi Nicholas, I think I'll backport your ZipArchiveMember>>contentStreamFromEncoding: and I also have to backport UTF8TextConverter>>errorMalformedInput as well. It will solve my encoding problem on git archive loading. Nice. Thierry Le 19/06/2013 22:33, Nicolas Cellier a Ã©crit : > The change is very light, I applied it almost unchanged on Squeak (can't > remember which version was the first). > The only thing we neeed is to catch an UTF8Error. > > Since in Pharo there are two encoder/decoder hierarchies, and since that > of Zinc is cleaner, I made a bet on future and chose to make UTF8Error a > subclass of existing already Zn Encoding/Decoding exception. > > But we still use the old TextConverter hierarchy in MC, even in Pharo 3.0. > So the dependency on Zinc is totally arbitrary and un-necessary right > now; it does not exist in Smalltalk version. > It's just a bet on the future. > For a backport to 2.0, I would just use an UTF8Error like in Squeak and > avoid any dependency on Zinc. > > Nicolas > > > 2013/6/19 GOUBIER Thierry <thierry.goubier(a)cea.fr > <mailto:thierry.goubier@cea.fr>> > > StÃ©phane, > > I'll probably have a look at Nicolas fix anyway, but as it required > also a change to Zinc... then I started to worry. But it may be > better than trying to fix ZipArchive incorrect encoding issues from > the outside (by forcing an utf8 conversion out of the contents of > the ZipArchive members). > > If I manage to make sense of it, I'll put a enhancement request in > FogBuz with a slice. > > Yes, I think 30 is not that unstable, like 2.0 was before ... except > that I'm fairly dependent on the RPackage infrastructure, and I > prefer to wait until the RPackage refactoring is done ;-) > > Thierry > > ________________________________________ > De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org > <mailto:pharo-dev-bounces@lists.pharo.org>] de la part de StÃ©phane > Ducasse [stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>] > Date d'envoi : mercredi 19 juin 2013 21:21 > Ã : Pharo Development List > Objet : Re: [Pharo-dev] you may need to update your configurations > > > > > > >> Christophe. > >> > >> [1] https://pharo.fogbugz.com/default.asp?10801 > > > > Ouch. Does not bode too well for backporting that to Pharo 2.0. > > > > I'm feeling a bit down. It's either enduring bugs in 2.0 for a > year or so or fighting every few days with 3.0 and knowing that > anyway it's not production ready. I had to cope with 1.4 not being > able to handle utf8 in the same way. > > Thierry what we can do is the following: > have a look at the fix of nicolas and we can try to add to > th 2.0 batch but we should pay attention > not to introduce other bugs (because I'm afraid it will). > > BTW 30 is not that instable. > > > > The window for my next serious developpement with Pharo is around > 2014, so I guess I could just sit and wait. > > > > By the way, why the change in > MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ? > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 20, 2013