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

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

Re: [Pharo-dev] Cloud Hosting Tip

by kilon

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. -- View this message in context: http://forum.world.st/Pharo-dev-Cloud-Hosting-Tip-tp4693950p4694279.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 20, 2013

Fwd: [Esug-list] WE HIRE : SENIOR SMALLTALK / JAVA SOFTWARE DEVELOPER

by stephane ducasse

Begin forwarded message: > From: Bertrand Wunderlich <bwunderlich(a)nfs.lu> > Subject: [Esug-list] WE HIRE : SENIOR SMALLTALK / JAVA SOFTWARE DEVELOPER > Date: June 19, 2013 4:36:42 PM GMT+02:00 > To: esug-list(a)lists.esug.org > > Hi everybody, > > Leading Banking Services in Luxembourg is seeking : > > Software Developer - SMALLTALK / JAVA > > Role/Area : > developer to participate to technical design, coding, unit testing and bug fixing in the context of GVAS 2011. > > Qualifications/required skills : > Software engineer with advanced SMALLTALK and JAVA development skills. > Experience in smalltalk development is required. > If possible, experience in financial industry and ability to coach people. > English is the working language. > > Starting date : ASAP. > Estimated duration of the mission : until December 2014 (minimum). > Location : LUXEMBOURG. > Salary : negociable. > > Please send me your resume if you're interested in that offer. > > > Bertrand Wunderlich > Recruitment officer > > NFS S.A. > 4, Place de Strasbourg > L-2562 LUXEMBOURG > LUXEMBOURG > T : +352 20 40 80 42 > P : +352 661 500 151 > > www.nfs.lu > > > > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

June 20, 2013

pending backports for 2.0 summer

by Esteban Lorenzano

Hi, There are some issues marked as backport to 2.0 who need some attention, in case you guys really want them in the summer release. https://pharo.fogbugz.com/f/search/?ixFixFor=6&ixStatus=-2&sColumns=Categor… btw... I remember you that the place to commit slices for 2.0 is still the older inbox: http://ss3.gemstone.com/ss/PharoInbox/ cheers, Esteban

June 20, 2013

Re: [Pharo-dev] Barcodes

by Stephan Eggermont

So, this kind-of works. Both Artefact and Barcode repositories are not writable, so here is an artefact package that depends on barcode. ean13Test: aStream "drawing an EAN13" | pdfdoc aPage barcode sequence | barcode := BarcodeEAN13 value: '2109876543210'. sequence := barcode binarySequence. pdfdoc := PDFDocument new. aPage := PDFPage new. sequence withIndexDo: [:each :index | each = $1 ifTrue: [ aPage add: (PDFLineElement from: (20+index) pt @ 50 pt to: (20+index) pt @ 20 pt). ] ]. pdfdoc add: aPage. pdfdoc styleSheet drawColor: (PDFColor r: 0 g: 0 b: 0). pdfdoc exportTo: aStream

June 20, 2013