- Pharo-dev - lists.pharo.org

Re: [Pharo-project] PDF4Smalltalk (was: Artefact - a PDF framework)

by Christian Haider

Done :-) : http://www.smallcharts.de/download/PDFSourcesV126.zip (I don't want to learn how to use git right now...) Version 1.2.6 filed out from VW 7.8.1 with the FileOut30 goodie in Squeak/Pharo format. See https://gitorious.org/pdf4smalltalk/pages/PackageStructure for the package structure. (Package "Fonts for Windows" could not be filed out... - only needed for the FontExplorer (UI for looking into font structures)) Happy browsing (the runtime code alone is 1.7 MB)... If you want to really get a look of it, you should definitely let it run, i.e. get VW and load it. Christian > -----UrsprÃ¼ngliche Nachricht----- > Von: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project- > bounces(a)lists.gforge.inria.fr] Im Auftrag von Yanni Chiu > Gesendet: Donnerstag, 3. Mai 2012 00:01 > An: pharo-project(a)lists.gforge.inria.fr > Betreff: [Pharo-project] PDF4Smalltalk (was: Artefact - a PDF framework) > > On 02/05/12 12:33 PM, Christian Haider wrote: > >> I've not seen the code for PDF4Smalltalk, because I can't figure >> out > how to browse it without VW. > > > > Unfortunately, you can't :-( > > Could you file out the source code (.st or xml) and post a zip file to the > gitorious site - or, maybe BobN could do it, since he's looking at a port to > GemStone. It's a bit of a hurdle to download, install, refresh/update VW skills > - just to evaluate some code. (When I first heard you'd decided on GIT, I > briefly thought that Dale's Montecello/GIT would let me browse the code > easily - maybe this will be true, at some future date). > > >

May 3, 2012

Re: [Pharo-project] Standard input in Pharo?

by Sean P. DeNigris

Sean P. DeNigris wrote > > use stein -> use stdin Damn you, autocorrect ;-) -- View this message in context: http://forum.world.st/Standard-input-in-Pharo-tp2173080p4605173.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 3, 2012

Re: [Pharo-project] Standard input in Pharo?

by Sean P. DeNigris

Igor Stasenko wrote > > If you are on linux, you can do just: > > stream := FileStream readOnlyFileNamed: '/dev/stdin'. > stream nextLine > > Unfortunately, Squeak VM doesn't provides a default API for working > with stdin/out, > Is anyone able to use stein from inside an image? I found a lot of mailing list posts about it, esp. around Coral, but I'm not sure if it ever made it into the image... On Mac OS X Lion with recent Jenkins Cocoa Cog Jit VM, none of the following seemed to work (most hung the image): FileStream stdin upToEnd. FileStream stdin next. (FileStream fileNamed: '/dev/fd/0') readStream nextLine. (FileStream fileNamed: '/dev/stdin'). "Can't even create. symlink on OS X" -- View this message in context: http://forum.world.st/Standard-input-in-Pharo-tp2173080p4605172.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 3, 2012

Re: [Pharo-project] Artefact - a PDF framework

by Christian Haider

> Von: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project- > bounces(a)lists.gforge.inria.fr] Im Auftrag von Nicolas Cellier ... > Knowing that the PostscriptGraphicsContext just streams out graphics > primitives to the file, without needing any intermediate reification of > Postscript objects (except fonts), what was the point of such implementation > choice in PDF4Smalltalk? That is simple: in smallCharts, the product I use PDF for, I do have more or less elaborate models of graphical objects and text. But these are very much tied to the application and quite specific for my needs so that I don't think it is too useful for general consumption. Instead, some general abstractions/concepts should be developed bottom up based on broader use. Christian

May 3, 2012

[Pharo-project] FileSystem>>workingDirectory

by Sean P. DeNigris

"In Pharo1.4 #14439... The following changes the working directory as far as FS is concerned" FileSystem disk changeDirectory: '..'. "As confirmed by..." FileSystem disk workingDirectory. "But the system's default directory has not changed, as seen by" FileDirectory default "and must be changed by..." FileDirectory setDefaultDirectory: whatever I'm assuming this will be fixed as the system is weened off of FileDirectory et al, but just wanted to mention it... - S -- View this message in context: http://forum.world.st/FileSystem-workingDirectory-tp4605016.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 3, 2012

Re: [Pharo-project] multiple pharo images

by Serge Stinckwich

When you download a lot of images every week, this is nice to have a build number in order to recognize them. Regards, On Thu, May 3, 2012 at 4:20 AM, Francisco Garau <francisco.garau(a)gmail.com> wrote: > > How about Jenkins putting a build suffix to the images? -- something like Pharo-2.0.build-20040.image > > At the moment, all the build generate files with the same name. > > https://ci.lille.inria.fr/pharo/job/Pharo-2.0/41/ > > 2.0 #20040 > > Pharo-2.0.changes 13069724 > Pharo-2.0.image 18732936 > Pharo-2.0-one-click.zip 19242637 > Pharo-2.0.zip 14962904 -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

May 3, 2012

Re: [Pharo-project] OSProcess error in 1.3

by GastÃ³n Dall' Oglio

Hi David. I send some days ago a mail reporting "process never is completed" in Windows, and I propose similar steps to reproduce, see: http://forum.world.st/OSProcess-is-process-done-tp4569088p4570740.html Two notes about this previous mail: Two notes about this previous mail: I say "the image hang", but this was when I evaluate #waitForCommand: and obviously is related to that the external process is always marked as running, not just "when I open the image with OSProcess already loaded" how I says. Another, I do OSProcess command: 'cmd.exe /c dir' en windows 7, OSProcess command: 'dir' only work in windows xp. Well, I run this and both result in a always running process and thread: 1) OSProcess command: 'cmd.exe /c dir'. => always running process (although the associated underlying process is complete) 2) OSProcess thisOSProcess restartChildWatcherThread => always running thread. As I says in previous mail, if I unload and load OSProcess package then all begin to work fine. Then, I suspected that was needed rerun some class side initialize code to solve the problem. And yes!!! That is OSProcessAccessor initialize. I added that to ThisOSProcess>>startUp: resuming | aio | (aio := Smalltalk at: #AioEventHandler) ifNotNil: [ aio startUp: resuming ]. *OSProcessAccessor initialize.* self initializeThisOSProcess Regards. 2012/5/2 David T. Lewis <lewis(a)mail.msen.com> > Sean, > > Can you please try two things, in this order, and let me know which > one causes the problem to go away? > > 1) Save your image, exit, and restart. Then try > > (OSProcess command: 'ls') inspect > > and see if it results in a process proxy with run state "complete". > > 2) Restart the child watcher > > OSProcess accessor restartChildWatcherProcess. > (OSProcess command: 'ls') inspect > > and see if it results in a process proxy with run state "complete". > > Thanks, > Dave > > On Tue, May 01, 2012 at 10:22:44PM -0700, Sean P. DeNigris wrote: > > With the latest OSProcess package from SqS, when I save the image, I get: > > > > 2 May 2012 1:20:30 am > > > > VM: Mac OS - intel - 1073 - Croquet Closure Cog VM [CoInterpreter > > VMMaker-oscog-EstebanLorenzano.155] 21.0 > > Image: Pharo1.3 [Latest update: #13320] > > > > UndefinedObject(Object)>>doesNotUnderstand: #wait > > Receiver: nil > > Arguments and temporary variables: > > aMessage: wait > > exception: MessageNotUnderstood: receiver of "wait" > is nil > > resumeValue: nil > > Receiver's instance variables: > > nil > > > > [[event wait. > > processSynchronizationDelay wait. > > self changed: #childProcessStatus] repeat. > > nil] in UnixOSProcessAccessor>>grimReaperProcess > > Receiver: a UnixOSProcessAccessor on pid 22740 > > Arguments and temporary variables: > > event: nil > > processSynchronizationDelay: a Delay(20 msecs) > > Receiver's instance variables: > > dependents: a DependentsArray(a UnixProcess with pid > 22740) > > sessionIdentifier: #[104 195 160 79] > > canObtainSessionIdentifierFromPlugin: true > > hasTestEof: nil > > grimReaper: a Process in > > MorphicUIManager>>openDebuggerOn:context:label:content...etc... > > sigChldSemaphore: nil > > > > Weird... > > > > > > -- > > View this message in context: > http://forum.world.st/OSProcess-error-in-1-3-tp4602389.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

May 3, 2012

Re: [Pharo-project] multiple pharo images

by Camillo Bruni

we envision an archiving facility with nicely named zips. but the artifacts in there will be the same name => otherwise scripting builds gets too annoying On 2012-05-02, at 23:29, Yanni Chiu wrote: > On 02/05/12 5:20 PM, Francisco Garau wrote: >> How about Jenkins putting a build suffix to the images? -- something >> like *Pharo-2.0.build-20040.image* >> >> At the moment, all the build generate files with the same name. > > I prefer to have the same name, otherwise I have to do one of two things: (1) edit the build script of dependent jobs to have the new name, or (2) re-name the image and changes file to match the build script. I suspect that follow on build jobs is the reason for the current naming convention. > >

May 3, 2012

Re: [Pharo-project] PDF4Smalltalk (was: Artefact - a PDF framework)

by Dale Henrichs

Yanni, Getting close:) Martin Kobetic is making progress on Cypress for VW (the project covering cross dialect git)...not quite there yet... Dale ----- Original Message ----- | From: "Yanni Chiu" <yanni(a)rogers.com> | To: pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, May 2, 2012 2:59:59 PM | Subject: [Pharo-project] PDF4Smalltalk (was: Artefact - a PDF framework) | | On 02/05/12 12:33 PM, Christian Haider wrote: | >> I've not seen the code for PDF4Smalltalk, because I can't figure | >> out how to browse it without VW. | > | > Unfortunately, you can't :-( | | Could you file out the source code (.st or xml) and post a zip file | to | the gitorious site - or, maybe BobN could do it, since he's looking | at a | port to GemStone. It's a bit of a hurdle to download, install, | refresh/update VW skills - just to evaluate some code. (When I first | heard you'd decided on GIT, I briefly thought that Dale's | Montecello/GIT | would let me browse the code easily - maybe this will be true, at | some | future date). | | |

May 2, 2012

Re: [Pharo-project] Artefact - a PDF framework

by GastÃ³n Dall' Oglio

And in the last page of document says: "Next... Port to VA, GS, Pharo, Squeak (easy for Report4PDF, harder for Smalltalk4PDF)" 2012/5/2 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> > Sorry, I mean to capabilities of Report4PDF. > > > 2012/5/2 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> > >> Hi. >> >> Following the links in Bob blog, I get a pdf document showing >> capabilities of PDF4Smalltalk: >> >> http://www.stic.st/conferences/stic12/stic12-abstracts/pdf4smalltalk-based-… >> >> Regards. >> >> 2012/5/2 Christian Haider <Christian.Haider(a)smalltalked-visuals.com> >> >>> > Von: pharo-project-bounces(a)lists.gforge.inria.fr >>> [mailto:pharo-project- >>> > bounces(a)lists.gforge.inria.fr] Im Auftrag von Yanni Chiu >>> > >>> > On 02/05/12 10:53 AM, Sean P. DeNigris wrote: >>> > > >>> > > Stephan Eggermont wrote >>> > >> >>> > >> Don't you think it would be much less work to port Christian >>> Haider's >>> > >> work to Pharo? >>> > > >>> > > I was thinking the same thing. The usual Smalltalk duplication of >>> > > effort seems to have been taken to new heights with PDF libs ;-) >>> > >>> > I've loaded Artefact, browsed the code, tried the demos. >>> > >>> > I've not seen the code for PDF4Smalltalk, because I can't figure out >>> how to >>> > browse it without VW. >>> >>> Unfortunately, you can't :-( >>> >>> > However, looking at the examples at: >>> > https://gitorious.org/pdf4smalltalk/pages/Examples >>> > I get the (possibly mistaken) impression that the two frameworks do >>> slightly >>> > different things, but the final result is a PDF in both cases. >>> > >>> > Looking at the PDFDemos of Artefact, it's clear how text and tables >>> can be >>> > written. However, looking at the PDF4Smalltalk examples, it looks like >>> you >>> > have to position the text and tables in your own code. Of course, I >>> may be >>> > completely wrong about PDF4Smalltalk, since I've not seen the full >>> code >>> > base. >>> >>> I have not looked at Artefact, but from what I read, these are different >>> things, I guess. >>> PDF4Smalltalk is a system library providing full access to PDF. >>> PDF objects are regular Smalltalk objects which you can read from PDF >>> files or create them with code and write them as PDF. The PDF basics are >>> quite complete and robust (I use it for a few years in production now), >>> but there are also lots of features desired :-) (TrueType fonts and >>> bitmap images to name a few). >>> >>> It deals purely with PDF and does not add any higher concepts like >>> tables and other layouting facilities - in fact not even proper classes >>> for graphics or text... (high on my list when I find time). It is like >>> painting on a canvas: you are completely responsible for the placement >>> of everything. >>> To deal with that, Bob Nemec implemented Report4PDF which uses Seaside >>> like layouting for a report generator. It is done, works and is quite >>> nice! See >>> http://smalltalk-bob.blogspot.de/2012/01/pdf-report-and-law-of-demeter.h >>> tml<http://smalltalk-bob.blogspot.de/2012/01/pdf-report-and-law-of-demeter.html> >>> >>> I'd love if someone would port this to Pharo! I would help with >>> answering questions, but I have not time to do anything substantial in >>> the moment... >>> >>> Cheers, >>> Christian >>> >>> >> >

May 2, 2012