- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 1.1] #11051

by Marcus Denker

On Nov 19, 2009, at 9:26 PM, Lawson English wrote: > Marcus Denker wrote: >> 11051 >> ----- >> >> Issue 489: [Pending Etoy Cleaning] Morph >> cursor >> Issue 776: HTTPSocket class side duplicated code (removed superswiki methods) >> >> >> > > REL issue 776... Is there any functionality for https available or is > HttpsSocket still required? > No changes in functionality... this just cleaned up some eToy-related things. Marcus

Nov. 20, 2009

Re: [Pharo-project] OSProcess - working on gnuplot

by Adrian Lienhard

Hi Dave, On Nov 20, 2009, at 02:42 , David T. Lewis wrote: [...] > I am getting serious failures on CommandShellTestCase that still worry > me. For example, if I evaluate this (on Linux VM with Pharo image): > > (CommandShellTestCase selector: #testEvaluateOrMakePipelinesFrom) > debug Indeed, CommandShellTestCase isn't that stable as I first thought. I've run all tests of CommandShellTestCase in the Test runner multiple times: 1. run: all green 2. run: error in testPipeline75 (re-running this test succeeded, so I don't know what the error was) 3. run: test runner hangs in testIfThenElse02 because indefinitely waiting on completionSemaphore in #evaluatePipelines: restarted the VM 1. run: all green 2. run: same as 3 above 3. run: same as 3 above 4. run: error in testPipeline72 5. run: all green I haven't seen any defunct processes, though. [...] > Second question: > > Some of the failures you are getting look like things that I thought > that I had fixed in the past (but I'm not sure). The latest versions > from the SqueakSource repositories should be: > > OSProcess-dtl.53 > Tests-OSProcess-dtl.20 > CommandShell-dtl.40 > Tests-CommandShell-dtl.14 I have the same versions except for CommandShell-dtl.39 (I updated to 40 now). Let me know if I can be of any more help. Adrian > Could you please double check your versions of OSProcess, > CommandShell and > the unit tests to see if they match these MC versions? > > Thanks a lot, I really appreciate the help. And obviously I am going > to > have to go buy a Mac one of these days so I will not have to ask all > these dumb questions ;) > > Dave > > > On Thu, Nov 19, 2009 at 10:05:26PM +0100, Adrian Lienhard wrote: >> I took another try using a unix VM (3.11.3.2135 compiled from source) >> on OS X 10.5.8. It has the plugin version 4.3.3. Looks much better >> than with the Mac VM that has the outdated plugin! >> >> 409 run, 389 passes, 0 expected failures, 20 failures >> >> - The VM does not crash anymore >> - There are a couple of errors that go away if I change >> #useOldNetwork >> to return true >> >> - The following tests seem to fail due to assumptions about files and >> permissions that do not hold on OS X: >> ShellSyntaxTestCase>>#testExpandArgument03 >> ShellSyntaxTestCase>>#testExpandArgumentFrom01 >> UnixProcessAccessorTestCase>>#testIsExecutableForUserInGroup >> UnixProcessAccessorTestCase>>#testIsReadableForUserInGroup >> UnixProcessAccessorTestCase>>#testIsWritableForUserInGroup >> UnixProcessAccessorTestCase>>#testChDir >> >> - one or two tests fail sometimes, but not always. For example: >> UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses04 >> >> - The following tests, which fork the VM, do not work: >> PipeableOSProcessTestCase>>#testForkHeadlessSqueak >> PipeableOSProcessTestCase>>#testForkHeadlessSqueak2 >> PipeableOSProcessTestCase>>#testForkSqueak >> UnixProcessTestCase>>#testClassForkHeadlessSqueakAndDo >> UnixProcessTestCase>>#testClassForkHeadlessSqueakAndDoThenQuit >> UnixProcessTestCase>>#testClassForkSqueak >> UnixProcessTestCase>>#testClassForkSqueakAndDo >> UnixProcessTestCase>>#testClassForkSqueakAndDoThenQuit >> UnixProcessTestCase>>#testForkHeadlessSqueakAndDo >> UnixProcessTestCase>>#testForkHeadlessSqueakAndDoThenQuit >> UnixProcessTestCase>>#testForkSqueak >> UnixProcessTestCase>>#testForkSqueakAndDo >> UnixProcessTestCase>>#testForkSqueakAndDoThenQuit >> UnixProcessTestCase>>#testHeadlessChild >> >> For example running #testHeadlessChild I get to stdout: >> >> hello world from child process 1359 >> >> Segmentation fault >> >> 390493624 UnixProcess>forkHeadlessSqueakAndDoThenQuit: >> 390493524 >forkHeadlessSqueakAndDoThenQuit: >> 390493400 >headlessChild >> 390493264 UnixProcessTestCase>testHeadlessChild >> 390493172 TestCase>executeShould:inScopeOf: >> 390493080 BlockClosure>on:do: >> 390492988 TestCase>executeShould:inScopeOf: >> 390492876 TestCase>shouldnt:raise: >> 390491136 UnixProcessTestCase>testHeadlessChild >> 390491044 TestCase>performTest >> 390490952 TestCase>runCase >> >> >> If I run #testForSqueak I get >> >> The process has forked and you cannot use this CoreFoundation >> functionality safely. You MUST exec(). >> Break on >> __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ >> () to debug. >> The process has forked and you cannot use this CoreFoundation >> functionality safely. You MUST exec(). >> Break on >> __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ >> () to debug. >> The process has forked and you cannot use this CoreFoundation >> functionality safely. You MUST exec(). >> Break on >> __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ >> () to debug. >> The process has forked and you cannot use this CoreFoundation >> functionality safely. You MUST exec(). >> Break on >> __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ >> () to debug. >> The process has forked and you cannot use this CoreFoundation >> functionality safely. You MUST exec(). >> Break on >> __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ >> () to debug. >> The process has forked and you cannot use this CoreFoundation >> functionality safely. You MUST exec(). >> Break on >> __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ >> () to debug. >> >> Segmentation fault >> >> 390953340 DisplayScreen>forceToScreen: >> 390953248 DisplayScreen>forceDamageToScreen: >> 390953124 OrderedCollection>do: >> 390952960 DisplayScreen>forceDamageToScreen: >> 390952840 WorldState>forceDamageToScreen: >> 390869724 WorldState>displayWorld:submorphs: >> 390869632 PasteUpMorph>privateOuterDisplayWorld >> 390869540 PasteUpMorph>displayWorld >> 390869448 WorldState>displayWorldSafely: >> 390869356 BlockClosure>on:do: >> 390869244 BlockClosure>ifError: >> 390869096 WorldState>displayWorldSafely: >> >> >> From these tests it seems that the critical parts of OSProcess are >> actually working with this configuration (modulo the forking). >> >> Adrian >> >> On Nov 19, 2009, at 06:03 , David T. Lewis wrote: >> >>> On Wed, Nov 18, 2009 at 09:44:08PM -0500, David T. Lewis wrote: >>>> On Wed, Nov 18, 2009 at 05:14:04PM -0500, David T. Lewis wrote: >>>>> On Wed, Nov 18, 2009 at 08:55:50AM -0500, Schwab,Wilhelm K wrote: >>>>>> Dave, >>>>>> >>>>>> It would help to knock the MVC workspace out of the offending >>>>>> #initialize >>>>>> method and re-save the packages. In my experience, that simple >>>>>> change make >>>>>> the load hassle-free vs. the current situation. >>>>> >>>>> Bill, >>>>> >>>>> Good idea, thanks. I'll take a look at that when I get home. >>>> >>>> Well actually there were not any MVC references in #initialize. But >>>> CommandShell class>>initialize opens a shell window, and that was >>>> failing >>>> because text style 'Atlanta' no longer exists in Pharo. I fixed >>>> this, >>>> so if you update to CommandShell-dtl.40.mcz that failure will no >>>> longer >>>> occur. The shell window does not actually work, but at least the >>>> window >>>> opens properly now. One bug down, ??? to go ... >>> >>> Correction, the shell window *does* seem to be working, so this is >>> actually looking much better now. However, the CommandShellTestCase >>> does not pass (hangs up part way through, lots of zombie unix >>> processes >>> left unhandled). >>> >>> The other unit tests are passing, with the exception of the tests in >>> AioEventHandlerTestCase that use sockets. This is due to changes in >>> the socket support in Pharo, but I am not worried about these >>> failures >>> as they probably just require updates to the tests to match the >>> Pharo socket support. >>> >>> I am testing on Linux with a VM that I built locally. For OS X, an >>> updated OSProcessPlugin will need to be included with the VM, >>> otherwise >>> we will have VM crashes when handling external process exit. >>> >>> The main concerns now are: >>> >>> 1) Need an updated OSProcessPlugin for the Mac VM (for both Squeak >>> and Pharo) >>> >>> 2) Why does CommandShellTestCase on Pharo get hung up and leave >>> zombies? >>> >>> Note, CommandShellTestCase is a real stress test for OSProcess. It >>> does >>> a lot of concurrent process handling with pipelines of OS processes >>> interacting with Squeak/Pharo. If this test does not pass, then I am >>> not confident in the overall reliability of OSProcess. >>> >>> Dave >>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 20, 2009

Re: [Pharo-project] About end of line convention

by Peter Hugosson-Miller

Exactly! +100 FWIW, this us the behaviour of Textpad, my favourite Windoze text editor. -- Cheers, Peter. On 20 nov 2009, at 01.49, Martin McClure <martin(a)hand2mouse.com> wrote: > IMO, a useful behavior for a text file editor is to: > > * On open, detect the line end convention of the file and remember it. > This is not too hard to do as long as the file is in fact a text file > (if it's a binary file you shouldn't be using a text editor on it). > > * On save, save in the same line end convention that the file > previously > had. > > * On "save as" provide the opportunity to change the line end > convention > as well as the file name. > > * New files should default to the platform's line end convention, but > again be overridable on save. > > Regards, > > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 20, 2009

Re: [Pharo-project] About end of line convention

by Igor Stasenko

2009/11/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> The way how CIUS solves this shown at screenshot. >> >> My humble question: >> if i created a text file, what you think is more important to me: >> Â - being able to clearly read the text >> Â - or being able to see all control characters which may differ from >> OS to OS??? > > sorry but you are wrong. > I saw how this is done in CUIS and if you want to see the end line character > you can see them, else not. > I'm often burned with not having that and I think that his solution is cool. > >> My line of argumentation is, that text editor should serve for editing >> a text, but not some sort of binary-mode editing >> where text is a mix of usual symbols and non-human stuff, which having >> meaning only to computer. > > No > >> If i would want to see a binary contents of file, i use hex dump >> display/edit, but not text editor. >> (see another attachment) > > No > >> Use right tool for things you do. By making a single tool for serving >> everything - as result you getting a horrific & complex monster >> without any means how to manage it and improve. > > No > >> >>> He told me that in the squeak world people were pushing that the end of line is controlled by the platform. >> >> This is not correct. >> I am pushing the idea, that text editor should serve to edit and >> display text, and don't care about preserving or dealing with >> different line-end conventions. > > Then you did not got burn enough by moving files between OSes > I regularly spent time with tr on unix just to clean such kind of things. > Trust me, i burnt to the point that i don't want to see or hear about them again in my life. And Juan's editor displaying 'lf' glyphs is like 'wellcome back, to hell'. Squeak's text editor allows you to do some formatting, like changing font, emphasis, color and more special things like links etc.. And once you changing text using this, you can't represent it as plaing text without losing formatting information, and from that point preserving line ends becoming too minor issue comparing to fact that you can't preserve formatting. As to me, from this side, a text editor behaves like html renderer, while displaying control characters is analoguous to displaying html source instead of rendering it. Now tell me, have you seen html renderer , which instead of rendering page - showing you tags? Or if you prefer to see html source, then it is logical to diplay all other kinds of formatting with plain text (by using some kind of markup), instead of reflecting them visually. No? And then, don't you think that rendering html and displaying html is done using different tools, because obviously it is two different representations of same document. And nobody mixing them (you don't see any tags when browsing, while can see them when looking at source), while Juan's modification looks like a mixture of two different modes - 'raw' mode, when you can see source and rendering mode - when you see the designed document. Such kind of mixture is awfully wrong. So, if you want to see line feeds in text, then get rid of text formatting features first, or make two SEPARATE TOOLS, each specialized on different displaying mode. >> Instead, import should deal with >> normalizing the input to a form, edigible by editor, and then export >> layer (file-out or whatever) may be instructed to save edited file >> using one or other line-ends, but editor should use own convention(s) >> and free to choose own ways how internally store the edited text. >> >>> My point of view on this is : >>> Â Â Â Â - when I manipulate the text object may be we should have the platform convention. >>> Â Â Â Â - when I edit a file I should get the control because I may want to edit a file on mac with unix convention. >>> >>> So nicolas I saw that you pushed a slice about fixing end of line. >>> What is the design behind it? >>> >> >> Stef, you can always read a full discussion about it on squeak-dev archives. >> http://n4.nabble.com/support-of-various-line-ends-in-trunk-td622338.html#a6… > > No time for that now. > >> >>> Stef >>> _______________________________________________ >>> 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. >> <text.txt><cuis-editor.png><hexdump.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 > -- Best regards, Igor Stasenko AKA sig.

Nov. 20, 2009

Re: [Pharo-project] About end of line convention

by Schwab,Wilhelm K

+1 -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Thursday, November 19, 2009 8:59 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] About end of line convention Yes! Stef > IMO, a useful behavior for a text file editor is to: > > * On open, detect the line end convention of the file and remember it. > This is not too hard to do as long as the file is in fact a text file > (if it's a binary file you shouldn't be using a text editor on it). > > * On save, save in the same line end convention that the file > previously had. > > * On "save as" provide the opportunity to change the line end > convention as well as the file name. > > * New files should default to the platform's line end convention, but > again be overridable on save. > > Regards, > > -Martin > > _______________________________________________ > 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

Nov. 20, 2009

Re: [Pharo-project] About end of line convention

by StÃ©phane Ducasse

Yes! Stef > IMO, a useful behavior for a text file editor is to: > > * On open, detect the line end convention of the file and remember it. > This is not too hard to do as long as the file is in fact a text file > (if it's a binary file you shouldn't be using a text editor on it). > > * On save, save in the same line end convention that the file previously > had. > > * On "save as" provide the opportunity to change the line end convention > as well as the file name. > > * New files should default to the platform's line end convention, but > again be overridable on save. > > Regards, > > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 20, 2009

Re: [Pharo-project] About end of line convention

by StÃ©phane Ducasse

On Nov 20, 2009, at 1:39 AM, Stephan Eggermont wrote: > StÃ©phane Ducasse wrote: >> When we edit a file we should be in control about that we want to > have. > I don't think so. What we want is an end of line. I don't care how it > is represented. Most of the time. But when you need to know this is important to know it. > (Actually, I do. It should be out-of-band instead of a character. > But I'm not going to get that). > Only when saving/exporting (and importing) can I be interested > in the representation. Default should be platform, as most people > are not interested in implementation problems. Yes probably. > >> In CUIS when you edit a file you can decide the convention or change > it. > I don't like that. It is fine for a hex editor, but not for text. why if by default you get your default platform? > > Stephan Eggermont > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 20, 2009

Re: [Pharo-project] About end of line convention

by StÃ©phane Ducasse

> > The way how CIUS solves this shown at screenshot. > > My humble question: > if i created a text file, what you think is more important to me: > - being able to clearly read the text > - or being able to see all control characters which may differ from > OS to OS??? sorry but you are wrong. I saw how this is done in CUIS and if you want to see the end line character you can see them, else not. I'm often burned with not having that and I think that his solution is cool. > My line of argumentation is, that text editor should serve for editing > a text, but not some sort of binary-mode editing > where text is a mix of usual symbols and non-human stuff, which having > meaning only to computer. No > If i would want to see a binary contents of file, i use hex dump > display/edit, but not text editor. > (see another attachment) No > Use right tool for things you do. By making a single tool for serving > everything - as result you getting a horrific & complex monster > without any means how to manage it and improve. No > >> He told me that in the squeak world people were pushing that the end of line is controlled by the platform. > > This is not correct. > I am pushing the idea, that text editor should serve to edit and > display text, and don't care about preserving or dealing with > different line-end conventions. Then you did not got burn enough by moving files between OSes I regularly spent time with tr on unix just to clean such kind of things. > Instead, import should deal with > normalizing the input to a form, edigible by editor, and then export > layer (file-out or whatever) may be instructed to save edited file > using one or other line-ends, but editor should use own convention(s) > and free to choose own ways how internally store the edited text. > >> My point of view on this is : >> - when I manipulate the text object may be we should have the platform convention. >> - when I edit a file I should get the control because I may want to edit a file on mac with unix convention. >> >> So nicolas I saw that you pushed a slice about fixing end of line. >> What is the design behind it? >> > > Stef, you can always read a full discussion about it on squeak-dev archives. > http://n4.nabble.com/support-of-various-line-ends-in-trunk-td622338.html#a6… No time for that now. > >> Stef >> _______________________________________________ >> 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. > <text.txt><cuis-editor.png><hexdump.png>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 20, 2009

Re: [Pharo-project] OSProcess - working on gnuplot

by David T. Lewis

Adrian, Thanks *very* much for the detailed feedback. I do want to ask a couple more questions if your patience holds up. First question: I am getting serious failures on CommandShellTestCase that still worry me. For example, if I evaluate this (on Linux VM with Pharo image): (CommandShellTestCase selector: #testEvaluateOrMakePipelinesFrom) debug I find that the test never completes. It is stuck waiting for the various external processes to be cleaned up, and the console output shows the zombie processes whose exit signals have not yet been handled by the image: lewis@linux-6xfc:~/squeak/Pharo/pharo1.0-10495-rc1dev09.11.3> ps PID TTY TIME CMD 3877 pts/51 00:00:00 bash 9695 pts/51 00:00:00 xterm 10060 pts/51 00:00:45 squeakvm 10268 pts/51 00:00:00 ls <defunct> 10269 pts/51 00:00:00 cat <defunct> 10271 pts/51 00:00:00 cat <defunct> 10272 pts/51 00:00:00 wc <defunct> 10273 pts/51 00:00:00 ps <defunct> 10274 pts/51 00:00:00 cat <defunct> 10275 pts/51 00:00:00 cat <defunct> 10279 pts/51 00:00:00 ps lewis@linux-6xfc:~/squeak/Pharo/pharo1.0-10495-rc1dev09.11.3> Do you see problems like this when you run CommandShellTestCase? Second question: Some of the failures you are getting look like things that I thought that I had fixed in the past (but I'm not sure). The latest versions from the SqueakSource repositories should be: OSProcess-dtl.53 Tests-OSProcess-dtl.20 CommandShell-dtl.40 Tests-CommandShell-dtl.14 Could you please double check your versions of OSProcess, CommandShell and the unit tests to see if they match these MC versions? Thanks a lot, I really appreciate the help. And obviously I am going to have to go buy a Mac one of these days so I will not have to ask all these dumb questions ;) Dave On Thu, Nov 19, 2009 at 10:05:26PM +0100, Adrian Lienhard wrote: > I took another try using a unix VM (3.11.3.2135 compiled from source) > on OS X 10.5.8. It has the plugin version 4.3.3. Looks much better > than with the Mac VM that has the outdated plugin! > > 409 run, 389 passes, 0 expected failures, 20 failures > > - The VM does not crash anymore > - There are a couple of errors that go away if I change #useOldNetwork > to return true > > - The following tests seem to fail due to assumptions about files and > permissions that do not hold on OS X: > ShellSyntaxTestCase>>#testExpandArgument03 > ShellSyntaxTestCase>>#testExpandArgumentFrom01 > UnixProcessAccessorTestCase>>#testIsExecutableForUserInGroup > UnixProcessAccessorTestCase>>#testIsReadableForUserInGroup > UnixProcessAccessorTestCase>>#testIsWritableForUserInGroup > UnixProcessAccessorTestCase>>#testChDir > > - one or two tests fail sometimes, but not always. For example: > UnixProcessWin32FileLockingTestCase>>#testCooperatingProcesses04 > > - The following tests, which fork the VM, do not work: > PipeableOSProcessTestCase>>#testForkHeadlessSqueak > PipeableOSProcessTestCase>>#testForkHeadlessSqueak2 > PipeableOSProcessTestCase>>#testForkSqueak > UnixProcessTestCase>>#testClassForkHeadlessSqueakAndDo > UnixProcessTestCase>>#testClassForkHeadlessSqueakAndDoThenQuit > UnixProcessTestCase>>#testClassForkSqueak > UnixProcessTestCase>>#testClassForkSqueakAndDo > UnixProcessTestCase>>#testClassForkSqueakAndDoThenQuit > UnixProcessTestCase>>#testForkHeadlessSqueakAndDo > UnixProcessTestCase>>#testForkHeadlessSqueakAndDoThenQuit > UnixProcessTestCase>>#testForkSqueak > UnixProcessTestCase>>#testForkSqueakAndDo > UnixProcessTestCase>>#testForkSqueakAndDoThenQuit > UnixProcessTestCase>>#testHeadlessChild > > For example running #testHeadlessChild I get to stdout: > > hello world from child process 1359 > > Segmentation fault > > 390493624 UnixProcess>forkHeadlessSqueakAndDoThenQuit: > 390493524 >forkHeadlessSqueakAndDoThenQuit: > 390493400 >headlessChild > 390493264 UnixProcessTestCase>testHeadlessChild > 390493172 TestCase>executeShould:inScopeOf: > 390493080 BlockClosure>on:do: > 390492988 TestCase>executeShould:inScopeOf: > 390492876 TestCase>shouldnt:raise: > 390491136 UnixProcessTestCase>testHeadlessChild > 390491044 TestCase>performTest > 390490952 TestCase>runCase > > > If I run #testForSqueak I get > > The process has forked and you cannot use this CoreFoundation > functionality safely. You MUST exec(). > Break on > __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ > () to debug. > The process has forked and you cannot use this CoreFoundation > functionality safely. You MUST exec(). > Break on > __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ > () to debug. > The process has forked and you cannot use this CoreFoundation > functionality safely. You MUST exec(). > Break on > __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ > () to debug. > The process has forked and you cannot use this CoreFoundation > functionality safely. You MUST exec(). > Break on > __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ > () to debug. > The process has forked and you cannot use this CoreFoundation > functionality safely. You MUST exec(). > Break on > __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ > () to debug. > The process has forked and you cannot use this CoreFoundation > functionality safely. You MUST exec(). > Break on > __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ > () to debug. > > Segmentation fault > > 390953340 DisplayScreen>forceToScreen: > 390953248 DisplayScreen>forceDamageToScreen: > 390953124 OrderedCollection>do: > 390952960 DisplayScreen>forceDamageToScreen: > 390952840 WorldState>forceDamageToScreen: > 390869724 WorldState>displayWorld:submorphs: > 390869632 PasteUpMorph>privateOuterDisplayWorld > 390869540 PasteUpMorph>displayWorld > 390869448 WorldState>displayWorldSafely: > 390869356 BlockClosure>on:do: > 390869244 BlockClosure>ifError: > 390869096 WorldState>displayWorldSafely: > > > From these tests it seems that the critical parts of OSProcess are > actually working with this configuration (modulo the forking). > > Adrian > > On Nov 19, 2009, at 06:03 , David T. Lewis wrote: > > > On Wed, Nov 18, 2009 at 09:44:08PM -0500, David T. Lewis wrote: > >> On Wed, Nov 18, 2009 at 05:14:04PM -0500, David T. Lewis wrote: > >>> On Wed, Nov 18, 2009 at 08:55:50AM -0500, Schwab,Wilhelm K wrote: > >>>> Dave, > >>>> > >>>> It would help to knock the MVC workspace out of the offending > >>>> #initialize > >>>> method and re-save the packages. In my experience, that simple > >>>> change make > >>>> the load hassle-free vs. the current situation. > >>> > >>> Bill, > >>> > >>> Good idea, thanks. I'll take a look at that when I get home. > >> > >> Well actually there were not any MVC references in #initialize. But > >> CommandShell class>>initialize opens a shell window, and that was > >> failing > >> because text style 'Atlanta' no longer exists in Pharo. I fixed this, > >> so if you update to CommandShell-dtl.40.mcz that failure will no > >> longer > >> occur. The shell window does not actually work, but at least the > >> window > >> opens properly now. One bug down, ??? to go ... > > > > Correction, the shell window *does* seem to be working, so this is > > actually looking much better now. However, the CommandShellTestCase > > does not pass (hangs up part way through, lots of zombie unix > > processes > > left unhandled). > > > > The other unit tests are passing, with the exception of the tests in > > AioEventHandlerTestCase that use sockets. This is due to changes in > > the socket support in Pharo, but I am not worried about these failures > > as they probably just require updates to the tests to match the > > Pharo socket support. > > > > I am testing on Linux with a VM that I built locally. For OS X, an > > updated OSProcessPlugin will need to be included with the VM, > > otherwise > > we will have VM crashes when handling external process exit. > > > > The main concerns now are: > > > > 1) Need an updated OSProcessPlugin for the Mac VM (for both Squeak > > and Pharo) > > > > 2) Why does CommandShellTestCase on Pharo get hung up and leave > > zombies? > > > > Note, CommandShellTestCase is a real stress test for OSProcess. It > > does > > a lot of concurrent process handling with pipelines of OS processes > > interacting with Squeak/Pharo. If this test does not pass, then I am > > not confident in the overall reliability of OSProcess. > > > > Dave > > > > > > _______________________________________________ > > 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

Nov. 20, 2009

Re: [Pharo-project] About end of line convention

by Igor Stasenko

2009/11/20 Martin McClure <martin(a)hand2mouse.com>: > IMO, a useful behavior for a text file editor is to: > > * On open, detect the line end convention of the file and remember it. > This is not too hard to do as long as the file is in fact a text file > (if it's a binary file you shouldn't be using a text editor on it). > > * On save, save in the same line end convention that the file previously > had. > > * On "save as" provide the opportunity to change the line end convention > as well as the file name. > > * New files should default to the platform's line end convention, but > again be overridable on save. > +1 exactly what i want. + detect if file starting with BOM character, then use utf-8 decoding. > Regards, > > -Martin > > _______________________________________________ > 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.

Nov. 20, 2009