November 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] About end of line convention

by Stephan Eggermont

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. (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. >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. Stephan Eggermont

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>: > Hi nicolas > > I was dicussing today with juan vuletich about the management of end of line convention and I think that > he is right. When we edit a file we should be in control about that we want to have. > In CUIS when you edit a file you can decide the convention or change it. 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??? 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. If i would want to see a binary contents of file, i use hex dump display/edit, but not text editor. (see another attachment) 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. > 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. 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… > 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.

Nov. 20, 2009

[Pharo-project] About end of line convention

by StÃ©phane Ducasse

Hi nicolas I was dicussing today with juan vuletich about the management of end of line convention and I think that he is right. When we edit a file we should be in control about that we want to have. In CUIS when you edit a file you can decide the convention or change it. He told me that in the squeak world people were pushing that the end of line is controlled by the platform. 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

Nov. 19, 2009

Re: [Pharo-project] Conseils for develop a grid

by Alain Plantec

nullPointer a Ã©crit : > > The problem is than scroller left never change when scrollbar is scrolled. > IÂ´m seeing the state of scrollpane and donÂ´t see a change in a var when is > scrolled. My purpose with that is change position of row header to same X of > rows panel. > Hi nullPointer, argh, yes, you're right, sorry for this bad answer :( The good answer is that you can use the scroller offset. In order to update the position of the header when the horizontal scrollbar is changed, you can redefine Scrollpane>>hScrollBarValue: YourGridClass>>hScrollBarValue: scrollValue super hScrollBarValue: scrollValue. self updateHeader "makes use of 'scroller offset x' in order to change header position" hope that it will help this time. Cheers Alain

Nov. 19, 2009

Re: [Pharo-project] Conseils for develop a grid

by nullPointer

The problem is than scroller left never change when scrollbar is scrolled. IÂ´m seeing the state of scrollpane and donÂ´t see a change in a var when is scrolled. My purpose with that is change position of row header to same X of rows panel. Regards and thanks for the help :) Alain Plantec-4 wrote: > > Hi all, > > The left reference is given by > scroller left > > Did you have a look at MorphTreeMorph. It seems that it is very near of > your grid. > www.squeaksource.com/Momo > It includes 2 examples. > LazyClassList new openOn: Object > see attached screenshot. > Cheers > Alain > > nullPointer a Ã©crit : >> IÂ´m developing a grid for my UIBuilder. For the moment show a few cells >> and >> columns.The rows area is a ScrollPane widget with TableLayout policy. The >> rows header is another panel. >> In vertical scroll the behavior is correct, the rows scrolling and the >> header is fixed -> >> >> http://img43.imageshack.us/i/capturadepantalla200911w.png/ >> >> >> my problem is in the horizontal scroll, in that case rows area scroll >> good, >> but obviosly the header columns dont "match" with the rows columns, only >> is >> a panel -> >> >> http://img10.imageshack.us/i/capturadepantalla200911f.png/ >> >> >> IÂ´m catching the "scrolling" event, but i dont have a position reference >> for >> relocate the rows header panel. The rows area position donÂ´t change when >> is >> scrolled, is strange. >> >> I hope to me to have expressed wellâ¦ :| >> > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- View this message in context: http://n2.nabble.com/Conseils-for-develop-a-grid-tp4028690p4034563.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 19, 2009

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

by Adrian Lienhard

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

Nov. 19, 2009

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

by Lawson English

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? Lawson

Nov. 19, 2009

Re: [Pharo-project] Fwd: Bug in Nile extension to Traits

by Marcus Denker

On Nov 19, 2009, at 8:43 PM, StÃ©phane Ducasse wrote: > It should probably be integrated in pharo. I added http://code.google.com/p/pharo/issues/detail?id=1471 Marcus

Nov. 19, 2009

Re: [Pharo-project] Fwd: Bug in Nile extension to Traits

by Adrian Lienhard

What is this method useful for? Adrian On Nov 19, 2009, at 20:43 , StÃ©phane Ducasse wrote: > It should probably be integrated in pharo. > > Stef > > Begin forwarded message: > >> From: Oscar Nierstrasz <oscar(a)iam.unibe.ch> >> Date: November 19, 2009 5:43:09 PM GMT+01:00 >> To: Damien Pollet <damien.pollet(a)inria.fr>, Damien Cassou <damien.cassou(a)gmail.com >> > >> Cc: Stephane Ducasse <stephane.ducasse(a)inria.fr> >> Subject: Bug in Nile extension to Traits >> >> >> Hi guys, >> >> There is an annoying bug in TraitBehavior>>allUsersOrSubclasses >> >> It fails to collect the traits that are immediate users of the >> given trait. >> >> I was planning to post a Pharo issue and bug fix, when I realized >> it is not even in the Core! >> >> I attached the missing test and the fix. Perhaps you should >> integrate this into Nile. >> >> (I discovered this while updating my traits lecture for the >> Smalltalk course.) >> >> Cheers, >> - on >> > <TraitBehavior-allUsersOrSubclasses.st><TraitModelTest.st> >> >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 19, 2009

[Pharo-project] Fwd: Bug in Nile extension to Traits

by StÃ©phane Ducasse

It should probably be integrated in pharo. Stef Begin forwarded message: > From: Oscar Nierstrasz <oscar(a)iam.unibe.ch> > Date: November 19, 2009 5:43:09 PM GMT+01:00 > To: Damien Pollet <damien.pollet(a)inria.fr>, Damien Cassou <damien.cassou(a)gmail.com> > Cc: Stephane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Bug in Nile extension to Traits > > > Hi guys, > > There is an annoying bug in TraitBehavior>>allUsersOrSubclasses > > It fails to collect the traits that are immediate users of the given trait. > > I was planning to post a Pharo issue and bug fix, when I realized it is not even in the Core! > > I attached the missing test and the fix. Perhaps you should integrate this into Nile. > > (I discovered this while updating my traits lecture for the Smalltalk course.) > > Cheers, > - on > > >

Nov. 19, 2009