April 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] ImageWriter, the SystemTracer's son

by Guillermo Polito

Hi Edgar, On Thu, Apr 26, 2012 at 4:46 PM, Edgar De Cleene <edgardec2005(a)gmail.com>wrote: > > > > El 4/26/12 10:19 AM, "Guillermo Polito" <guillermopolito(a)gmail.com> > escribiÃ³: > > Now it is fixed :). Tested it in a clean 2.0 image and worked :). > > > > Guillermo: > I like duplicate all steps. > Dowloaded a clean all in one 2.0. > You have a script for loading and test Hazelnut and all your new work ? > The only stable code part of the project is this :P. The other is kind of experimental yet, and is on another repository... So, for the image writer the script is: " load " Gofer it squeaksource3: 'ImageWriter'; package: 'ImageWriter-Core'; package: 'ImageWriter-ObjectFormats'; package: 'ImageWriter-Tests'; load " use the image writer " HzImageWriter new format: HzCogImageFormat new; "or HzInterpreterImageFormat new" imageFileName: 'someFile.image'; onInitializeDo: [ "Some initialization?" ]; "this is optional, probably the same as an startup script, probably nonsense" writeImage: Smalltalk "Yes, we provide the our lovely global Smalltak, but any SmalltalkImage instance could be" > > > Cheers > > Edgar >

April 26, 2012

Re: [Pharo-project] OSProcess - is process done?

by DeNigris Sean

> Hi Sean, > > An fread() call will block when reading from a unix pipe unless the pipe > end has been set to nonblocking mode (see #primSQFileSetNonBlocking:). So the #upToEnd problem was solved by sending #setNonBlockingOutput. So the following simple in-image ssh client works: p := PipeableOSProcess command: '/usr/bin/expect /path/to/expect_file.exp ', password, ' ', ipAddress. p setNonBlockingOutput. "This was added. Otherwise, #upToEnd hangs the image" p nextPutAll: 'ls', Character cr asString. p upToEnd. p nextPutAll: 'pwd', Character cr asString. p upToEnd. The reason that I didn't think to do this before is that I thought the whole point of #upToEnd was that it was *inherently* non-blocking... > - Open a test runner and run CommandShellTestCase... Yes, they all passed except the PipeableOSProcessTestCase ones... The other problem ("p := PipeableOSProcess waitForCommand: 'ps -ax -o pid,command'" hangs forever) is not happening right now. It's returning as soon as the process is finished, so I'll have to get back to you if it pops up again... Thanks for all the help! And is a fix required for #upToEnd based on the above? Sean

April 26, 2012

Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk

by H. Hirzel

On 4/21/12, Bernhard Pieber <bernhard(a)pieber.com> wrote: > Am 21.04.2012 um 22:22 schrieb "phil(a)highoctane.be" <phil(a)highoctane.be>: >> Yeah VM works on iOS. > Cool! > >> My use case is private, nothing fancy. I just value having decent >> TextEditor and friends. >> >> For an OO thing like Smalltalk Pharo, it would be a shame to now have a >> top notch UI kit for editing text. > I totally agree. That's one reason why I started the Styled Text Editor > project. ;-) Great effort! Are there screen shots of the implementation available somewhere? In which format does it save the files? RTF? HTML? Something else? --Hannes > Cheers, > Bernhard > >> I hope to be able to provide several decent samples so that newcomers >> don't have to go through the same pain as I go through now. >> >> Phil >> >> 2012/4/21 Bernhard Pieber <bernhard(a)pieber.com> >> Thanks for the encouragement! >> >> The necessary funding depends on the effort of course, and this in turn >> depends on the approach one uses for porting. We have an idea how to do >> the port to Pharo as an external package. Do you have a concrete use case >> in mind? >> >> Cheers, >> Bernhard >> >> P.S. Did you succeed building the Mac VM on Xcode 4.3 yet? >> >> Am 21.04.2012 um 21:17 schrieb "phil(a)highoctane.be" <phil(a)highoctane.be>: >> >>> Great news! >>> >>> I am currently busy looking after Text, TextAttributes, TextConstants, >>> Paragraph... and god, it went through the grinder and it shows. >>> >>> I understand the reasons that led to such things but Collections-Text is >>> in need of improvement for sure. >>> >>> How much funding would be necessary to get this port done? >>> >>> Phil >>> >>> 2012/4/21 Bernhard Pieber <bernhard(a)pieber.com> >>> Dear Smalltalkers, >>> >>> I am very happy to announce that the Styled Text Editor for the brand new >>> Cuis 4.0 is now available on GitHub [1]. The Styled Text Editor was first >>> presented by me at last year's ESUG in Edinburgh [2]. Thanks to ESUG the >>> presentation was recorded [3]. >>> >>> The Styled Text Editor is a framework for rich text editing using styles >>> as known from popular word processors like Apple Pages or Microsoft Word. >>> It features paragraph and character styles, allowing easy text formatting >>> using styles only. It is intended for applications where users need to >>> work with good looking rich text in a simple and fast way. >>> >>> Rich text commonly refers to text with formatting information like >>> different fonts, sizes, alignments, and emphasis. To make editing as >>> simple as possible instead of individual formatting information end users >>> apply styles to parts of the text. Editing is made fast by keyboard >>> shortcuts for text navigation, selection, and styles selection. Where >>> possible the feel of widely used rich text editors is supported. >>> >>> It includes many features like >>> - numbered and bulleted list paragraph styles >>> - support for images >>> - multiple level undo and redo >>> - text completion using various glossaries including a dictionary of >>> English with about 166.000 words >>> - RTF clipboard (on OS X VMs with the ClipboardExtendedPlugin) >>> >>> The Styled Text Editor is developed in Cuis with the plan to eventually >>> port it to Squeak and Pharo. The development of the Styled Text Editor >>> inspired many changes to Cuis itself, and It is the first package to use >>> the brand new DVCS based development process for external packages for >>> Cuis 4.0. >>> >>> The idea and funding was provided by me, Bernhard Pieber and my company >>> Software Generation. The implementation was done by Juan Vuletich, the >>> mastermind behind Cuis. Thanks Juan for the close cooperation. It was and >>> still is great fun to work with you. >>> >>> We are looking forward to feedback from you. Fork it on GitHub [1], >>> create issues and send us pull requests. ;-) >>> >>> Cheers, >>> Bernhard Pieber >>> >>> [1] https://github.com/bpieber/Cuis-StyledTextEditor >>> [2] >>> http://www.esug.org/wiki/pier/Conferences/2011/Schedule-And-Talks/StyledTex… >>> [3] >>> http://www.youtube.com/watch?v=pUoVbvwspi8&list=PL813665D04A2E4C0A&index=7&… >>> >>> >>> >>> -- >>> Philippe Back >>> "Helping you hit the top 3 outcomes you really want to achieve" >>> >>> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: >>> phil(a)highoctane.be | Web: http://philippeback.eu | Blog: >>> http://philippeback.be >>> >>> High Octane SPRL >>> rue cour Boisacq 101 >>> 1301 Bierges >>> >> >> >> >> -- >> Philippe Back >> "Helping you hit the top 3 outcomes you really want to achieve" >> >> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be >> | Web: http://philippeback.eu | Blog: >> http://philippeback.be >> >> High Octane SPRL >> rue cour Boisacq 101 >> 1301 Bierges >> >

April 26, 2012

Re: [Pharo-project] OSProcess - is process done?

by DeNigris Sean

Begin forwarded message: > From: "David T. Lewis" <lewis(a)mail.msen.com> > Subject: Re: OSProcess - is process done? > Date: April 25, 2012 7:47:22 PM EDT > To: DeNigris Sean <sean(a)clipperadams.com> > > On Wed, Apr 25, 2012 at 01:50:35PM -0400, DeNigris Sean wrote: >> David, does this tell us anything? I'm *very* happy to help solve this on the Mac, since I use OSP extensively... >> >> From: "Sean P. DeNigris [via Smalltalk]" <ml-node+s1294792n4587479h37(a)n4.nabble.com> >> Subject: Re: OSProcess - is process done? >> Date: April 25, 2012 1:48:18 PM EDT >> To: "Sean P. DeNigris" <sean(a)clipperadams.com> >> >>> >>> p upToEnd. "This hangs, even though there is output in the pipe" >> I debugged this with the Stack VM from Jenkins. It's hanging in sqFileBasicPluginPrims.c on line 360: >> bytesRead = fread(dst, 1, count, file); >> >> This line seems to never return, although the docs suggest that it should just return an error or less data if the requested data is not available. > > Hi Sean, > > An fread() call will block when reading from a unix pipe unless the pipe > end has been set to nonblocking mode (see #primSQFileSetNonBlocking:). > A blocking read call like this will block the entire VM, and if you get > into a condition where you are reading from a blocking pipe that has no > data available, the VM and image will lock up until data is available > in the pipe (which might be never). It's not likely that there would be > anything wrong with the fread call itself, so there must be something > going on here that gets us into a state where a read is being done on a > pipe that has no data, and that has not set to nonblocking mode. Right now > I can't guess what is doing that, but based on what you see in gdb it is > probably that kind of situation. > > In order to debug the problem, here is what I would suggest doing: > > - Edit the two methods String>>withoutTrailingBlanks and String>>#withBlanksTrimed, > and comment out (or delete) the #deprecated:on: lines in these two methods. > This will allow you to run the unit tests for OSProcess/CommandShell. Do not > just turn off the deprecation warning preferences, this does not work. > > - Load the latest versions of both OSProcess and CommandShell from SqueakSource. > Load the full CommandShell package, and ignore the warnings about two MVC classes. > I made some minor updates to these packages yesterday to support Pharo, so > it's best if you can use the latest versions. > > - Open a test runner and run CommandShellTestCase. These will exercise > PipeableOSProcess (note that the PipeableOSProcessTestCase tests will fail > on Cog, so do not worry about those for now). I find that CommandShellTestCase > tests are all green for Pharo running on Cog using the latest Linux Cog VM from > Eliot's site. There may be differences on OS X (e.g. paths to commands), but > it will be easy to figure out if that is happening. Hopefully you will get > all green tests, or just some explainable failures related to OS X differences. > > If the above works for you on a Mac, then we will know that basic PipeableOSProcess > functionality is working and we must have some kind of problem in the way > it is being used on OS X, or maybe what you are doing is exposing a bug that > is not covered by the unit tests. On the other hand, if the CommandShellTestCase > tests fail, that should lead us to some other kind of problem. > > Dave >

April 26, 2012

Re: [Pharo-project] Confused about #isDirectory

by Sean P. DeNigris

Sean P. DeNigris wrote > > The changed snippet is... > Issue 79: primitiveDirectoryLookup returns wrong dir flag http://code.google.com/p/cog/issues/detail?id=79 -- View this message in context: http://forum.world.st/Confused-about-isDirectory-tp4589441p4590357.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 26, 2012

Re: [Pharo-project] Confused about #isDirectory

by Sean P. DeNigris

Should have been... Sean P. DeNigris wrote > > Removing the call returns the correct value (true) for "'/private/tmp' > asFileReference isDirectory" > -- View this message in context: http://forum.world.st/Confused-about-isDirectory-tp4589441p4590346.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 26, 2012

Re: [Pharo-project] Confused about #isDirectory

by Sean P. DeNigris

Sean P. DeNigris wrote > > For /private/var, <primitive: 'primitiveDirectoryLookup' module: > 'FilePlugin'> returns false for the dir flag... still investigating... > sqSqueakOSXFileDirectoryInterface-resolvedAliasFiles: calls stringByStandardizingPath on the filePath, which the manual [1] states may "Remove an initial component of â/privateâ from the path if the result still indicates an existing file or directory (checked by consulting the file system).". This returns /var for /private/var, which is a symlink. Removing the call returns the correct value (true) for "". Also, all Tests-Files and Filesystem-Tests pass in 1.4. The changed snippet is (I also fixed the misspelled variable "compoents" to "components"): - (NSString *)resolvedAliasFiles:(NSString *)filePath { NSArray *components = [filePath pathComponents]; // removed stringByStandardizingPath call NSString *thisComponent; NSString *path = [[NSString new] autorelease]; for (thisComponent in components) { [1] https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foun… -- View this message in context: http://forum.world.st/Confused-about-isDirectory-tp4589441p4590343.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 26, 2012

Re: [Pharo-project] Pharo and the rest of the ecosystem

by Casimiro de Almeida Barreto

On 26-04-2012 11:31, Sean P. DeNigris wrote: > > Yes this is the key! It's not "let's build all these great frameworks on top > of the system", but "we need a clean, beautiful system that people can use > and explore and build on without tearing their hair out in frustration" [1] > and some of the components are so messy that the only clear path forward is > replacement. This is not a criticism of Squeak. Many parts of Squeak (and > Squeak itself was intended as just a "tool to think" about the next > evolution) were spikes, not real implementations but experiments. So the > usual advice that it's better to clean than to rewrite does not apply. > Proofs of concept are meant to be thrown away! Yes, that's true: some times replacements are necessary. Thing is that historical smalltalk distros were not devised in modular way. Particularly they didn't have the idea of core system and foundation classes and that lead to a development model that depended on non orthogonal stuff (meaning: at some point it got difficult to insulate causes of trouble and fixing one thing lead to problems in other things). Situation was further complicated by the fact that sometimes problems found in certain areas were "solved" by building new packages to deal with them and these new packages should live side by side with old ones. In terms of maintenance it is pretty like hell. The efforts of generating minimal images (cores) are extremely healthy: to do so it is necessary to eliminate much undesired inter-dependencies. Besides people are minding about the real necessity of having different things to deal with the same stuff (like file and directory management). Another aspect of it is that people are enhancing code where possible or just replacing things that are fubar. I guess that one thing for immediate future of an open source "industry grade" smalltalk is to define foundation classes to deal with core functionality (file and directory management, (inter)networking, multimedia, interfacing with OS, user interface (including seamless use of full screen display and OpenGL), etc, etc, etc. IMO, interfacing with OS and foreign libraries is something that must be seen "with love" because FFI is not well behaved and as VMs were designed for past generation x86-32bit (mono-core single-thread) architectures. There is a lot to do in terms of porting things to the new 64bit multi-core multi-thread hardware architectures. I remember that around 2010 there were hot discussions about having multi-core multi-thread support in VM but now things are quite silent. Also, the last things I saw about 64bit images date from 2010. > > Each of these components brings us closer to a clean, beautiful, > Smalltalk-inspired system "and users are expected to build on that > directly". The Smalltalk-inspired part is crucial also. Until I got that, I > was plagued by questions of interoperability and backward-compatibility > (which are obviously still nice, but subordinate to evolution). > > I see Squeak and Pharo's goals aligning more and more and, sure, it is > frustrating to duplicate efforts. Although, maybe we'd all be complacent > without the friendly rivalry. As the Zen master said, "we'll see..." [2] > > [1] I can't imagine someone putting FileDirectory and friends through > serious use and not praying for something like Filesystem. And a programming > environment without built-in support for https?? Zodiac is a fundamental > piece of the system. These things are not "buzz", but core components that > let us get back to work and play, instead of beating our heads against > soul-crushing constructs like "FileDirectory extensionFor: file name" > instead of "file extension" > > [2] A boy is given a horse on his 14th birthday. Everyone in the village > says, âOh how wonderful.â But a Zen master who lives in the village says, > âWe'll see.â 'The boy falls off the horse and breaks his foot. Everyone in > the village says, âOh how awful.â The Zen master says, âWe'll see.â The > village is thrown into war and all the young men have to go to war. But, > because of the broken foot, the boy stays behind. Everyone says, âOh, how > wonderful.â The Zen master says, âWe'll see.â > > Cheers, > Sean > > -- > View this message in context: http://forum.world.st/Pharo-and-the-rest-of-the-ecosystem-tp4582839p4590003… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > Best regards, CdAB

April 26, 2012

Re: [Pharo-project] VNC for pharo 1.3 or 1.4

by Norbert Hartl

Am 26.04.2012 um 17:21 schrieb Hernan Wilkinson: > Hi > does anybody ported the implementation of VNC to pharo 1.3 or 1.4? > If so, could you share it? :-) > I use it daily on pharo 1.3. I load it via metacello. My baseline entry looks like this project: 'RFB' with: [ spec className: 'ConfigurationOfRFB'; file: 'ConfigurationOfRFB'; versionString: #'bleedingEdge'; repository: 'http://www.squeaksource.com/MetacelloRepository' ]; Norbert

April 26, 2012

[Pharo-project] VNC for pharo 1.3 or 1.4

by Hernan Wilkinson

Hi does anybody ported the implementation of VNC to pharo 1.3 or 1.4? If so, could you share it? :-) Thanks! Hernan. -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - 4311 - 8404** Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

April 26, 2012