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

Re: [Pharo-project] Spec Documentation

by Sean P. DeNigris

Benjamin Van Ryseghem-2 wrote > The paper submitted to IWST12 is up to date... Thanks, Ben! -- View this message in context: http://forum.world.st/Spec-Documentation-tp4651169p4651192.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 14, 2012

Re: [Pharo-project] Spec Documentation

by Benjamin

The paper submitted to IWST12 is up to date Latests things are missing (like dynamic layouts) but I will write a tech report about that soon I think :) You can find it here: http://www.esug.org/wiki/pier/Conferences/2012/International-Workshop---IWS… (at the end) Good luck Ben On Oct 14, 2012, at 7:37 PM, Sean P. DeNigris wrote: > It seems like there have been many recent improvements to Spec. What's the > best way to learn the latest features? Is there an updated doc? Examples of > latest features? > > Thanks, > Sean > > > > -- > View this message in context: http://forum.world.st/Spec-Documentation-tp4651169.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Oct. 14, 2012

Re: [Pharo-project] EncryptedMultiDisplayScanner, are you serious?

by Henrik Sperre Johansen

On 14.10.2012 10:52, phil(a)highoctane.be wrote: > I am always feeling like an archaelogist when looking at these things... > > Phil Funnily enough, that class in particular was added just half a year ago :) Cheers, Henry

Oct. 14, 2012

Re: [Pharo-project] Article On Modern Smalltalk

by StÃ©phane Ducasse

have a look at the Pharo success stories then: yesplan and others are cool. What will be your audience? and journal? Have a look at the Pharo vision document available on the consortium web page because it can give you a clear idea of where we are going. Stef > Thanks for the feedback so far. Gemstone/S will certainly be in there: > Thank you, Dale, I might have overlooked that. > > Alexandre: Yes, that is something I'm very interested in. Any kind of > live, linkable projects that demonstrate ST in real-world use. > > I'm glad to hear Squeak.org is being updated. That was one of my first > stops and the link rot there is impressive. > > All that said, while I want to touch on a lot of things, I'm not > creating a link dump. I want to focus more heavily on a few things. I > want to show people things that make them think "Man, I'm gonna go > check that out!" > > There's probably an encyclopedia worth of stuff out there; I want to > hit the highest of the high notes. >

Oct. 14, 2012

Re: [Pharo-project] Article On Modern Smalltalk

by blake

Thanks for the feedback so far. Gemstone/S will certainly be in there: Thank you, Dale, I might have overlooked that. Alexandre: Yes, that is something I'm very interested in. Any kind of live, linkable projects that demonstrate ST in real-world use. I'm glad to hear Squeak.org is being updated. That was one of my first stops and the link rot there is impressive. All that said, while I want to touch on a lot of things, I'm not creating a link dump. I want to focus more heavily on a few things. I want to show people things that make them think "Man, I'm gonna go check that out!" There's probably an encyclopedia worth of stuff out there; I want to hit the highest of the high notes.

Oct. 14, 2012

Re: [Pharo-project] pharo-2.0-tests Â» win - Build # 408 - Still Failing!

by Igor Stasenko

i love those error messages: rm: cannot remove directory `C:\\jenkins\\workspace\\pharo-2.0-tests\\label_exp\\win/Pharo-2.0-AfterRunningTests/package-cache': Is a directory -- Best regards, Igor Stasenko.

Oct. 14, 2012

Re: [Pharo-project] Need more consistent #lines

by Igor Stasenko

On 14 October 2012 13:56, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sun, 14 Oct 2012, Igor Stasenko wrote: > >> A total number of lines in string should be: >> one + number of line separators found. >> >> Explanation: a 'String cr/ crlf' stands for 'line separator'. >> By definition, a separator, is thing which separates two others.. i >> mean, there is no way how you can use 'separator' term >> without having TWO things which it separates. >> >> The problem is that #lines does not follows common sense: >> >> (String empty, String cr, String empty) lines size 1 >> >> so, our line separator "separates" one thing :) >> It means that we overload the definition: >> - a line separator separates two lines unless it is at the end of text. >> >> But think , how dearly this 'unless' will costs in terms of >> implementation! >> Everywhere where you may need to handle text, you should put this >> extra rule, and if you forget it, >> you will be punished.. >> >> >> Here what various #lines produces: >> >> ( 'A' ) lines size 1 >> ( 'A', String cr ) lines size 1 !!oops!!. >> >> ( String cr, 'A' ) lines size 2 >> ( 'A', String cr, 'A' ) lines size 2 >> >> ( 'A', String cr, 'A', String cr ) lines size 2 >> ( 'A', String cr, 'A', String cr ) lines size 2 !!oops!! > > > The above two examples are the same. ;) > oh,sorry, i meant ( 'A', String cr, 'A' ) lines size 2 ( 'A', String cr, , 'A', String cr ) lines size 2 !!oops!! > >> >> You may think this is fine, but lets look at the problem from another >> angle: >> >> self assert: (string1, String cr, string2) lineCount >= 2 >> >> The 'string1, String cr, string2' above is an insertion operation. >> We inserting a line separator between two arbitrary strings. >> Now, in what universe the total number of lines may not get increased >> after such insertion? >> >> So, it is simply inconsistent. Or maybe you happy to put extra code >> everywhere where you handling text, to do a special handling if last >> character is line separator? >> But we can avoid all that mess it in a first place, if we obey to common >> sense. > > > Read this before you do anything (wrong): > > "There is also some confusion whether newlines terminate or separate lines. > If a newline is considered a separator, there will be no newline after the > last line of a file. The general convention on most systems is to add a > newline even after the last line, i.e. to treat newline as a line > terminator.[citation needed] Some programs have problems processing the last > line of a file if it is not newline terminated. Conversely, programs that > expect newline to be used as a separator will interpret a final newline as > starting a new (empty) line." > I am more concerned about out little world in smalltalk. For instance, how we count number of lines in text editor. Let me demonstrate what way counting the number of lines is consistent with editor: when user opens a fresh editor with empty contents, he has a single empty line for editing: 1: '' now he can start typing: 1: 'abc' if you save this string into file, and load it back, you obviously should show same contents: 1: 'abc' so, even if there's no 'newline' at the end it is still 1 line of text. If you won't keep same perception between what you showing to user and how tools perceive it, you will get inconsistency (with all grave consequences, and numerous workarounds everywhere etc etc ) 'wc -l' shows you 0, while editor shows 1, so there is no consistency. If we favor user's experience, then in such perception, the real liar is wc, not text editor. now, lets assume that user continues editing that text and hits "enter". No matter what character(s) you will insert into the string contents (lf/cr/crlf whatever), you should now show TWO lines available for editing: 1: 'abc' 2: '' So, again, it is not a question, that most consistent way of treating cr/crlf/lf is to be a line separator, but not 'line terminating character(s)' or 'new line, but not always' bullshit. Now, you can say, that editor don't needs to be pedantic about it, and start not from empty string but from '' , String cr contents. But then users will lose ability to produce files without terminating 'cr', as well as empty files. (unless, of course you put extra code to remove last 'cr' when filing out, and add it back when filing in).. but once you start doing something like that, it leads exactly to what i want to prevent in a first place: extra code/logic to deal with inconsistency. -- Best regards, Igor Stasenko.

Oct. 14, 2012

[Pharo-project] Spec Documentation

by Sean P. DeNigris

It seems like there have been many recent improvements to Spec. What's the best way to learn the latest features? Is there an updated doc? Examples of latest features? Thanks, Sean -- View this message in context: http://forum.world.st/Spec-Documentation-tp4651169.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 14, 2012

Re: [Pharo-project] Need more consistent #lines

by David T. Lewis

On Sun, Oct 14, 2012 at 02:23:43PM +0200, Nicolas Cellier wrote: > Yes, that's weird. > But I think the inconsistency comes from Unix that insist on having a > terminating LF. Not so. The line end convention on Unix is consistent with what Igor is expecting to see. But it's just a convention that is generally adopted by programs written for Unix, that's all. The operating system does nothing to enforce it. > > (FileDirectory default fileNamed: 'foo') truncate; nextPut: $a; close. > > $ od -c foo > 0000000 a > 0000001 > > $ wc -l foo > 0 foo > > (FileDirectory default fileNamed: 'foo') truncate; nextPut: $a; lf; close. > > $ od -c foo > 0000000 a \n > 0000002 > > $ wc -l foo > 1 foo > > In the past I had to care of appending a terminal line ending > character to make sure some unix scripts/tools would work. > For example remember that not having a terminal line ending in C > source can lead to a warning or error cdepending on your > compiler/flags... > Unfortunately, we have to admit that common sense in case of line > ending has been a bit perverted by our dear OS providers... Record-oriented file systems are quite common, and are still widely used. If you have an operating system (such as Unix or Windows) without record-oriented files, then common sense would tell you to adopt a line ending convention and use it consistently in all programs that need to read "records". Given that records in a file might be empty or blank, it would also be good common sense to ensure that an empty record at the end of a file should not go missing just because it is at the end of the file. Dave

Oct. 14, 2012

Re: [Pharo-project] Need more consistent #lines

by Nicolas Cellier

Yes, that's weird. But I think the inconsistency comes from Unix that insist on having a terminating LF. (FileDirectory default fileNamed: 'foo') truncate; nextPut: $a; close. $ od -c foo 0000000 a 0000001 $ wc -l foo 0 foo (FileDirectory default fileNamed: 'foo') truncate; nextPut: $a; lf; close. $ od -c foo 0000000 a \n 0000002 $ wc -l foo 1 foo In the past I had to care of appending a terminal line ending character to make sure some unix scripts/tools would work. For example remember that not having a terminal line ending in C source can lead to a warning or error cdepending on your compiler/flags... Unfortunately, we have to admit that common sense in case of line ending has been a bit perverted by our dear OS providers... Nicolas 2012/10/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > http://code.google.com/p/pharo/issues/detail?id=6807 > > Stef > >> A total number of lines in string should be: >> one + number of line separators found. >> >> Explanation: a 'String cr/ crlf' stands for 'line separator'. >> By definition, a separator, is thing which separates two others.. i >> mean, there is no way how you can use 'separator' term >> without having TWO things which it separates. >> >> The problem is that #lines does not follows common sense: >> >> (String empty, String cr, String empty) lines size 1 >> >> so, our line separator "separates" one thing :) >> It means that we overload the definition: >> - a line separator separates two lines unless it is at the end of text. >> >> But think , how dearly this 'unless' will costs in terms of implementation! >> Everywhere where you may need to handle text, you should put this >> extra rule, and if you forget it, >> you will be punished.. >> >> >> Here what various #lines produces: >> >> ( 'A' ) lines size 1 >> ( 'A', String cr ) lines size 1 !!oops!!. >> >> ( String cr, 'A' ) lines size 2 >> ( 'A', String cr, 'A' ) lines size 2 >> >> ( 'A', String cr, 'A', String cr ) lines size 2 >> ( 'A', String cr, 'A', String cr ) lines size 2 !!oops!! >> >> You may think this is fine, but lets look at the problem from another angle: >> >> self assert: (string1, String cr, string2) lineCount >= 2 >> >> The 'string1, String cr, string2' above is an insertion operation. >> We inserting a line separator between two arbitrary strings. >> Now, in what universe the total number of lines may not get increased >> after such insertion? >> >> So, it is simply inconsistent. Or maybe you happy to put extra code >> everywhere where you handling text, to do a special handling if last >> character is line separator? >> But we can avoid all that mess it in a first place, if we obey to common sense. >> >> -- >> Best regards, >> Igor Stasenko. >> > >

Oct. 14, 2012