- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Opening image multiple times - bug or feature?

by Douglas Brebner

Igor Stasenko wrote: > 2009/9/25 Douglas Brebner <squeaklists(a)fang.demon.co.uk>: > >> John M McIntosh wrote: >> >>> Actually the WIndows VM use to lie, might still, if you opened a file >>> READ/WRITE but it was read only, like on a CD, then the windows VM would >>> say SURE no problem. This caused grief for macintosh users using one- >>> click apps on a CD because we would cause a walkback saying we >>> couldn't open the file READ/WRITE. >>> >>> >> The problem I had was code that was written on unix that opened the same >> file twice in write mode in the initialization methods. Broke nastily on >> windows with confusing exceptions and leaking file handles iirc. >> >> >> BTW, opening an image twice at the same time on windows give the >> "changes file not accessible" popup at startup of the second image. >> >> > Right, because on windows you can obtain an exclusive write-lock on a > file for a process and disallow others > to open it for writing. > AFAIK, POSIX systems also allowing locking the file handle through > using ioctl(). > > Yep, and windows isn't the only one that does this by default, it's merely the most common :)

Sept. 26, 2009

Re: [Pharo-project] Titles of tool windows are inappropriate

by StÃ©phane Ducasse

Thanks andrew On Sep 26, 2009, at 2:42 AM, Andrew P. Black wrote: > Inspectors on an object foo say "foo on NewInspector" in the title. > They should just say "foo". Workspaces say "Shout Workspace"; that's > an implementation detail. I put a changeset in the bug database to > fixes these annoyances. (Issue 1245) > > Andrew > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2009

Re: [Pharo-project] CAnalyer

by Schwab,Wilhelm K

Sig, Is it something you have made available? One snag in my world is that the "code" is not always something that can be compiled. However, for GSL and other libraries of interest, the code is valid, if not full of macro-based annoyances and other distractions. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Friday, September 25, 2009 11:03 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] CAnalyer 2009/9/26 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > I was digging around on Squeak Source for OSProcess and friends, and ran across CAnalyzer. Â Are there any papers on it? Â How robust is it? Â What does it extract from C code? Â For example, might one put the GSL (www.gnu.org/software/gsl) header files into it, pull out all of the structure definitions and function prototypes, and generate LOTS of FFI code to make a wrapper? Â Just a thought... > I having a modified version of SWIG, which can parse C++ files, including classes and nested classes, to produce smalltalk code wrappers. Reproducing the SWIG in smalltalk would be very time consuming. But it would be cool to have a C/C++ parser implementation. SWIG is not only parsing, its also doing macro preprocessing, so its can't be fooled with macros :) > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2009

Re: [Pharo-project] CAnalyer

by Igor Stasenko

2009/9/26 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > I was digging around on Squeak Source for OSProcess and friends, and ran across CAnalyzer. Â Are there any papers on it? Â How robust is it? Â What does it extract from C code? Â For example, might one put the GSL (www.gnu.org/software/gsl) header files into it, pull out all of the structure definitions and function prototypes, and generate LOTS of FFI code to make a wrapper? Â Just a thought... > I having a modified version of SWIG, which can parse C++ files, including classes and nested classes, to produce smalltalk code wrappers. Reproducing the SWIG in smalltalk would be very time consuming. But it would be cool to have a C/C++ parser implementation. SWIG is not only parsing, its also doing macro preprocessing, so its can't be fooled with macros :) > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 26, 2009

[Pharo-project] OSProcess question

by Schwab,Wilhelm K

I see various ways to run something, none of which are quite what I want. The objective is to run openssl in a particular directory. I have no need to make this portable (unless you mean running on all of Ubuntu, Debian, Slackware, etc. <g>), so #forkAndExec:...workingDirectory: would almost be ok, **but**, I need to wait around for the result. In truth, there are a few things that have to happen in sequence; perhaps I could simply write multiple lines to the command string. Still, in the interest of idealism, it would be nice to run the commands on other than the Pharo main thread (no sense diving into something that might not return[*]), and to know when the work is done, and to get the different steps to happen in sequence. There was mention of tests for OSProcess (which might provide clues), but I have not been able to find them. Any hints? Bill [*] insert Windows joke here :)

Sept. 26, 2009

[Pharo-project] CAnalyer

by Schwab,Wilhelm K

I was digging around on Squeak Source for OSProcess and friends, and ran across CAnalyzer. Are there any papers on it? How robust is it? What does it extract from C code? For example, might one put the GSL (www.gnu.org/software/gsl) header files into it, pull out all of the structure definitions and function prototypes, and generate LOTS of FFI code to make a wrapper? Just a thought... Bill

Sept. 26, 2009

[Pharo-project] Titles of tool windows are inappropriate

by Andrew P. Black

Inspectors on an object foo say "foo on NewInspector" in the title. They should just say "foo". Workspaces say "Shout Workspace"; that's an implementation detail. I put a changeset in the bug database to fixes these annoyances. (Issue 1245) Andrew

Sept. 26, 2009

Re: [Pharo-project] CairoGraphics

by Ken Treis

On Sep 25, 2009, at 10:57 AM, StÃ©phane Ducasse wrote: > cool For anyone who's been playing with this, I just posted another new revision of Alien that fixes the platform sizes to match C platform sizes. Not sure what I was thinking in the first go-around. Anyhow, if you load Alien-Core-kdt.58 in Pharo, you'll need to re-initialize Alien: Alien initialize In other news, I've got CairoGraphics mostly working in GemStone (2.3.1) now too, running on top of an "Alien Lite" that provides support for the types of function calls I need to make. If anyone is interested in this, email me directly and I'll send you the code once I've worked out the remaining major bugs. Ken > > > On Sep 25, 2009, at 7:19 PM, Ken Treis wrote: > >> Hi Damien, >> >> Yes it definitely works -- at least for me, on Mac OS X. Recent VMs >> from John McIntosh have the plugin already, though on the mac it >> only searches for libraries in a few select places and it doesn't >> accept absolute paths. Hopefully this will be resolved soon; for now >> I've symlinked the library into my Squeak VM's plugins folder. >> >> On Linux you may have to compile a VM yourself to get the plugin; I >> know it's in the VM source tree. >> >> For a quick demo, try: >> >>> |image cr backgroundGradient textGradient| >>> image := CRImageSurface format: CRFormat argb32 extent: 300@200. >>> cr := image context. >>> backgroundGradient := CRLinearGradient from: 0@0 to: 150@200. >>> backgroundGradient addStopAt: 0 color: Color white. >>> backgroundGradient addStopAt: 1 color: Color lightGray. >>> cr >>> source: backgroundGradient; >>> paint. >>> cr moveTo: 30@100. >>> cr >>> selectFontFace: 'Sans'; >>> fontSize: 40. >>> cr textPath: 'Hello, World!'. >>> cr >>> source: Color green; >>> strokePreserve. >>> textGradient := CRLinearGradient from: 0@50 to: 300@50. >>> textGradient addStopAt: 0 color: Color blue alpha: 0.2. >>> textGradient addStopAt: 1 color: Color blue alpha: 0.8. >>> cr >>> source: textGradient; >>> fill. >>> image writeToPng: '/Users/kdt/Desktop/hello.png'. >> >> This isn't anything super exciting to look at, but if you've got the >> IA32ABI plugin and have set up CRLibrary class>>libraryPath to point >> to the Cairo library, you should be able to see the output >> (attached). I'll try to post a more impressive demo soon. >> >> >> Ken >> >> On Sep 25, 2009, at 2:08 AM, Damien Cassou wrote: >> >>> Hi Ken, >>> >>> I'm going to have 4 students working during 4 months on Smalltalk. I >>> would like to get a Cairo working implementation. What about >>> yours/Travis'? What can we do with it? Can we draw something in >>> Pharo? >>> Does it work? >>> >>> Thank you >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Lambdas are relegated to relative obscurity until Java makes them >>> popular by not having them." James Iry >> >> -- >> Ken Treis >> Miriam Technologies, Inc. >> <hello.png>_______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Ken Treis Miriam Technologies, Inc.

Sept. 25, 2009

Re: [Pharo-project] Help with Rotating a Box

by Nicolas Cellier

http://bugs.squeak.org/view.php?id=6511 2009/9/25 Andrew P. Black <black(a)cs.pdx.edu>: > I've been playing with a Morphic implementation of "Joe the box" for an > intro programming course. Â It shouldn't be hard, right? > > The problem is rotation. Â It's easy to rotate a polygon morph, but I can't > get a TextMorph (for the name) to rotate and stay centered. Â My next attempt > (attached), was to use a transformation morph. Â This almost works, except > that when rotating from a non-manhattan orientation, smurfs get left on the > display. > > The code is attached. > > > > > > > I try doing this in a workspace: > > joe := NamedBoxMorph2 new. > joe name: 'Fred'. > joe openInWorld. > joe color: Color lightBlue. > joe turn: -45. > joe turn: 45. > > Do the > > Â Â Â Â joe turn: +/- 45 > > a few times. Â Bits of the rectangle are left on the display. Â Is this a bug > in morphic, or a bug in my code (more likely)? Â Is tehre an easy fix/ > > The critical method from the filein is this one, I think: > > BoxMorph2 >> initialize > Â Â Â Â "initialize this BoxMorph so that it looks like a Box in BoxWorld" > Â Â Â Â | rectangle b | > Â Â Â Â super initialize. > Â Â Â Â smoothing := 3. > Â Â Â Â b := Rectangle origin: 85 @ 200 extent: 80 @ 80. > Â Â Â Â rectangle := RectangleMorph new. > Â Â Â Â rectangle bounds: b. > Â Â Â Â rectangle color: Color transparent. > Â Â Â Â rectangle borderWidth: 1. > Â Â Â Â self addMorphCentered: rectangle. > Â Â Â Â self bounds: b. > > I tired making the bounds of the boxMorph a pixel or two bigger (in the last > line): this didn't help. > > Any ideas? > > Â Â Â Â Andrew > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 25, 2009

[Pharo-project] Help with Rotating a Box

by Andrew P. Black

I've been playing with a Morphic implementation of "Joe the box" for an intro programming course. It shouldn't be hard, right? The problem is rotation. It's easy to rotate a polygon morph, but I can't get a TextMorph (for the name) to rotate and stay centered. My next attempt (attached), was to use a transformation morph. This almost works, except that when rotating from a non-manhattan orientation, smurfs get left on the display. The code is attached. I try doing this in a workspace: joe := NamedBoxMorph2 new. joe name: 'Fred'. joe openInWorld. joe color: Color lightBlue. joe turn: -45. joe turn: 45. Do the joe turn: +/- 45 a few times. Bits of the rectangle are left on the display. Is this a bug in morphic, or a bug in my code (more likely)? Is tehre an easy fix/ The critical method from the filein is this one, I think: BoxMorph2 >> initialize "initialize this BoxMorph so that it looks like a Box in BoxWorld" | rectangle b | super initialize. smoothing := 3. b := Rectangle origin: 85 @ 200 extent: 80 @ 80. rectangle := RectangleMorph new. rectangle bounds: b. rectangle color: Color transparent. rectangle borderWidth: 1. self addMorphCentered: rectangle. self bounds: b. I tired making the bounds of the boxMorph a pixel or two bigger (in the last line): this didn't help. Any ideas? Andrew

Sept. 25, 2009