- Pharo-dev - lists.pharo.org

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

by HernÃ¡n Morales Durand

Hi guys, I think a renderer or editor should be completely unaware about the underlying format of a file. A renderer could be concerned about text drawing, glyphs buffering (when appropiate, i.e. non-latin scripts), display maintenance when scrolling, colouring, etc. An editor should manage searching data, editing large files, keyboard input, etc. But... if computer gurus of the ' 70 invented 6 forms of end-of-line, one per operating system, and they didn't thought in terms of objects, let's leave it there. Conceptually end-of-line, line-breaks, form-feeds, line-separators and other control codes are computer artifacts necessary to format natural language text. They reveal an intention of a human to separate blocks of text semantically. But AFAIK there is no end-of-line grapheme in natural human languages, and so this inheritance from the Â´70 should be as isolated as possible, let's use an intuitionistic logic in a clever way and everything would become clear :) A formatter object, separated from rendering and editing, should end in a clean implementation. Using a formatter or another is a matter of the role of the human or the tool working with the file contents (it's so hard to assume things about humans...), but to me, Smalltalk should not be married anymore with the historical problems of others. Cheers, HernÃ¡n 2009/11/20 Igor Stasenko <siguctua(a)gmail.com>: > 2009/11/20 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 2009/11/20 Igor Stasenko <siguctua(a)gmail.com>: >>> 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. >>>> >> >> Hi Igor >> >>> >>> 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'. >>> >> >> Just what [] box are currently :) but a bit more informative. >> Don't flame me, I don't support this feature as a reasonnable default. >> >>> 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? >>> >> >> +1 >> So I'm happy to notice you should agree on my modification for >> rendering linefeed transparently in trunk. >> > > And i appreciate that. > I just think that conceptually, putting code which handling line feeds > in editor or renderer code is wrong. > Line feeds should be wiped out (converted) before passing to renderer/editor. > >>> 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. >>> >> >> Good sense of logic, that's a smart demonstration. >> But we have to be pragmatic too. >> If we limit this feature to poor text editors (character files), the >> demonstration about rich text does not really apply. >> Be it an option or a separate tool does not really matter. Notepad++ >> and lot of other string editors have this as an option. >> As long as it is an option in FileList tool and not the main >> behaviour, I think you could tolerate it, couldn't you ? >> > > I am fairly looking from pragmatic point: Don't left line ends mess > enter the image. > > If you want to see them when browsing files in file list - fine. > I just curious, how useful it is, since there is a plenty of other > tools in OS(es) which allow you do same (browsing file system + > viewing file contents), but in much more convenient manner. Maybe it > hurts someone's feelings, but i think that file list tool is thing > which too far from one which can called usable. It is simple, and lets > you view and open files, but i using it only when i need something to > be loaded into image , and i am always know what file(s) i want to > load before opening file list tool. And i closing file list > immediately after loading necessary files, and never using it to > search for files or browse the file system, simply because i'm not a > masochist. > > But lets get back to editor: > i have no idea for what purpose this mess (cr/lf) should get past the > import barriers and appear inside browser or workspace. Anyone wants > to deal with such mess there? > So, here is straightly pragmatic point: leave this mess where it came > from - ouside world. > > A plain text is not a bitmap image, which requires a bit-identical > rendering and color matching and as soon as it is readable, there is > nothing else we need. > > As a last sidenote: i really like how HTML standard deals with it: it > treats any control characters as a white space - be it space, cr, lf, > tab etc, and using a markup for indicating line breaks or new > paragraphs. > This makes renderer to be completely agnostic from weirdness, which > comes from ancient terminal-based ages. > >> cheers >> >> Nicolas >> > > -- > 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

Nov. 21, 2009

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

by Henrik Sperre Johansen

On 20.11.2009 22:30, Nicolas Cellier wrote: > We must separate the matters. > - how should we display the line-feed (independently from their source) > - how should the FileList tool handle various conversions (line end, > encodings,...) > > Old squeak and current Pharo both display an ugly [] box in case there > is a line feed in a String. > > From this point of view, displaying a boxed [lf] in Cuis is already a > big progress :), though I did not follow the same path in trunk. > > Concerning the file tool, +100 for the reasonnable default behavior on read. > But that should not be the sole option. > > For example, I have plenty of mixed line end conventions files. This > is due to people editing the files in heterogeneous environments. You > can judge that this is silly, I perfectly agree, but I can't fight. It > just exists that's a fact. Once you admit that, the bad players are > the applications not handling correctly these mixed conventions files. > Squeak/Pharo are bad players when they try to smartly > detectLineEndConvention, they are not smart at all and introduce > spurious line breaks when they write back with same guessed > convention. > > That's why I HAVE TO be able to CONTROL the read behaviour too, and > not let smart tools decide for me. Transparent line end is one of the > options. > As noticed by Igor, same for encodings of course. > > As for the display, my opinion is that most of the time we just don't > want to see the line endings. > That's why I changed this in trunk to be transparent (more exactly as > transparent if following a cr, as a line break otherwise) > This enables to not care at all for converting external world > input->image in most cases. > I still have to care about converting image->output to external world, > though, I think we all agree on that, so +100 too for the save as > proposals > (hehe, I also have some cases when I do not care at all, because I > have a smart tool chain handling mixed conventions, so again > transparent will be an option). > > In some particular situations we do care and wish to visually control > the line ends. An hex editor is not that fine because we are speaking > of text here, not binary data, and an hex editor generally fails to > interpret the line breaks and leads to hardly readable data. > I personnally use notepad++ and change a display parameter to show > [cr] [lf] boxes. That's what Juan is addressing in Cuis, and I think > it would be simple to incorporate this feature as another option in > the file browser, so we could eventually do it. Anyway, I agree, not > as the default behavior... > > All in all, I think we mostly agree, and should reach a consensus. > > cheers > > Nicolas > +1000 If I'd had time to write a reply to the topic, this post would be i, so thanks for writing it already. :) Cheers, Henry

Nov. 20, 2009

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

by StÃ©phane Ducasse

david thanks for chasing this difference. I would love to be able to help but I'm concurrently bad :). Stef > Hi Adrian, > > Overall, it does look like the basic OSProcess functions that most people > would use are working as long as an up to date plugin is available. > > The remaining issue that is relevant to the Pharo image (as opposed to > OSProcess running on any other image) is this CommandShellTestCase issue. > I think we are seeing different, but presumably related, symptoms of some > underlying problem. The tests in CommandShellTestCase do some rather complex > things with lots of processes, semaphore synchronization and so on. So I > think I will need to somehow whittle the problem down to some simpler test > that can provide some more reproduceable symptoms. > > My working assumption is that one of the following is true: > > 1) There is something different in Pharo versus Squeak that is exposing > an existing bug in OSProcess/CommandShell. This is quite likely. > > 2) The CommandShellTestCase is exposing an issue in Pharo related to > Semaphore handling, Delay scheduling, or Process scheduling. The seems > less likely than #1, but still possible because these tests do drive > a lot of interacting processes, and might expose an issue the "normal" > users would never see. > > One thing that I know could produce the sort of symptoms that I am seeing > would be anything that intermittently permitted a signal to a Semaphore > to be missed. This type of problem causes OSProcess to "miss" the exit > of one of its external processes, leading to zombie Unix processes and > tests in Pharo/Squeak that fail to run to completion. > > For that reason, if anyone can think of any changes to process scheduling > and semaphore handling, that might give me an idea of where to look. > > Thanks for all the help, > Dave > > > _______________________________________________ > 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

Ok I read everything. Igor I agree with you about not showing tags but the system still show [] and let me import [lf] files and fucked up my code. Each time I save VW code to import it into pharo I have to run some scripts to clean that. Here is what I understood - could we try to make sure that when something is loaded in the image it by default follow image convention? For example I fill in a cs that contains lf I should get something consistent in the image - would be nice to see [lf] instead of [] and remove all of them from the image - for filelist would be nice to see and be able to change the end of the line character - Now I was wondering what is the status at the level of the stream? Ie can I load a file which has lf and say stream convertLFToCr? Stef > We must separate the matters. > - how should we display the line-feed (independently from their source) > - how should the FileList tool handle various conversions (line end, > encodings,...) > > Old squeak and current Pharo both display an ugly [] box in case there > is a line feed in a String. > From this point of view, displaying a boxed [lf] in Cuis is already a > big progress :), though I did not follow the same path in trunk. > > Concerning the file tool, +100 for the reasonnable default behavior on read. > But that should not be the sole option. > > For example, I have plenty of mixed line end conventions files. This > is due to people editing the files in heterogeneous environments. You > can judge that this is silly, I perfectly agree, but I can't fight. It > just exists that's a fact. Once you admit that, the bad players are > the applications not handling correctly these mixed conventions files. > Squeak/Pharo are bad players when they try to smartly > detectLineEndConvention, they are not smart at all and introduce > spurious line breaks when they write back with same guessed > convention. > > That's why I HAVE TO be able to CONTROL the read behaviour too, and > not let smart tools decide for me. Transparent line end is one of the > options. > As noticed by Igor, same for encodings of course. > > As for the display, my opinion is that most of the time we just don't > want to see the line endings. > That's why I changed this in trunk to be transparent (more exactly as > transparent if following a cr, as a line break otherwise) > This enables to not care at all for converting external world > input->image in most cases. > I still have to care about converting image->output to external world, > though, I think we all agree on that, so +100 too for the save as > proposals > (hehe, I also have some cases when I do not care at all, because I > have a smart tool chain handling mixed conventions, so again > transparent will be an option). > > In some particular situations we do care and wish to visually control > the line ends. An hex editor is not that fine because we are speaking > of text here, not binary data, and an hex editor generally fails to > interpret the line breaks and leads to hardly readable data. > I personnally use notepad++ and change a display parameter to show > [cr] [lf] boxes. That's what Juan is addressing in Cuis, and I think > it would be simple to incorporate this feature as another option in > the file browser, so we could eventually do it. Anyway, I agree, not > as the default behavior... > > All in all, I think we mostly agree, and should reach a consensus. > > cheers > > Nicolas > > 2009/11/20 Peter Hugosson-Miller <oldmanlink(a)gmail.com>: >> 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 >> >> _______________________________________________ >> 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 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/11/20 Igor Stasenko <siguctua(a)gmail.com>: >> 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. >>> > > Hi Igor > >> >> 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'. >> > > Just what [] box are currently :) but a bit more informative. > Don't flame me, I don't support this feature as a reasonnable default. > >> 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? >> > > +1 > So I'm happy to notice you should agree on my modification for > rendering linefeed transparently in trunk. > And i appreciate that. I just think that conceptually, putting code which handling line feeds in editor or renderer code is wrong. Line feeds should be wiped out (converted) before passing to renderer/editor. >> 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. >> > > Good sense of logic, that's a smart demonstration. > But we have to be pragmatic too. > If we limit this feature to poor text editors (character files), the > demonstration about rich text does not really apply. > Be it an option or a separate tool does not really matter. Notepad++ > and lot of other string editors have this as an option. > As long as it is an option in FileList tool and not the main > behaviour, I think you could tolerate it, couldn't you ? > I am fairly looking from pragmatic point: Don't left line ends mess enter the image. If you want to see them when browsing files in file list - fine. I just curious, how useful it is, since there is a plenty of other tools in OS(es) which allow you do same (browsing file system + viewing file contents), but in much more convenient manner. Maybe it hurts someone's feelings, but i think that file list tool is thing which too far from one which can called usable. It is simple, and lets you view and open files, but i using it only when i need something to be loaded into image , and i am always know what file(s) i want to load before opening file list tool. And i closing file list immediately after loading necessary files, and never using it to search for files or browse the file system, simply because i'm not a masochist. But lets get back to editor: i have no idea for what purpose this mess (cr/lf) should get past the import barriers and appear inside browser or workspace. Anyone wants to deal with such mess there? So, here is straightly pragmatic point: leave this mess where it came from - ouside world. A plain text is not a bitmap image, which requires a bit-identical rendering and color matching and as soon as it is readable, there is nothing else we need. As a last sidenote: i really like how HTML standard deals with it: it treats any control characters as a white space - be it space, cr, lf, tab etc, and using a markup for indicating line breaks or new paragraphs. This makes renderer to be completely agnostic from weirdness, which comes from ancient terminal-based ages. > cheers > > Nicolas > -- Best regards, Igor Stasenko AKA sig.

Nov. 20, 2009

Re: [Pharo-project] Application screenshots

by StÃ©phane Ducasse

online end user shops. "It is a simple and easy online system you can use to create your own website online in order to promote and sell your products or services. Create your website now!" Stef On Nov 20, 2009, at 10:26 PM, Adrian Lienhard wrote: > Do we have slightly more information than the link alone? E.g., a > short description of the service and something about the company that > provides the service? > > Adrian > > On Nov 20, 2009, at 21:55 , StÃ©phane Ducasse wrote: > >> Adrian >> >> you can put a link to www.ibizlog.com >> :) >> >> Stef >> On Nov 20, 2009, at 9:13 PM, Adrian Lienhard wrote: >> >>> I changed the image to the one you suggested below. >>> >>> Adrian >>> >>> On Nov 20, 2009, at 19:34 , Gary Chambers wrote: >>> >>>> Of course, the screenshot piccy is from our "Report Builder"... >>>> though that >>>> will be integrated into the "Enterprise" version for customisation >>>> of the >>>> relabels (Database/barcode integration etc.). More reuse coming for >>>> that! >>>> Thanks for the exposure though, perhaps change the pic to >>>> http://www.flickr.com/photos/12018791@N06/4120335614/in/set-721576016593932… >>>> >>>> Regards, Gary >>>> >>>> ----- Original Message ----- >>>> From: "Adrian Lienhard" <adi(a)netstyle.ch> >>>> To: <Pharo-project(a)lists.gforge.inria.fr> >>>> Sent: Friday, November 20, 2009 6:25 PM >>>> Subject: Re: [Pharo-project] Application screenshots >>>> >>>> >>>>> Great, thanks for sharing! >>>>> >>>>> I added an entry to the top of >>>>> http://www.pharo-project.org/about/success-stories >>>>> >>>>> If other companies like to get their Pharo project featured on the >>>>> success stories page, please send me information. >>>>> >>>>> Cheers, >>>>> Adrian >>>>> >>>>> >>>>> On Nov 20, 2009, at 18:57 , Gary Chambers wrote: >>>>> >>>>>> Here for now: >>>>>> http://www.flickr.com/photos/12018791@N06/sets/72157601659393251/ >>>>>> >>>>>> Some explanation... >>>>>> >>>>>> The application is designed to improve efficiency with relabelling >>>>>> of packages/groups-of-packages within the logistics industry. >>>>>> Often >>>>>> the pre-existing labelling is hard to read and/or covered with >>>>>> polywrap etc. >>>>>> >>>>>> MBagger provides a simple means of rescanning labels with >>>>>> algorithmic clean-up suitable for re-printing with commerically >>>>>> available thermal printers (1 bit per pixel) >>>>>> >>>>>> Sorry for "plug" bust some details here: >>>>>> http://www.pinesoft.co.uk/what/logisticsproducts >>>>>> >>>>>> Certainly an interesting project. Leveraging the lean approach of >>>>>> Pharo with the visual appeal of Polymorph. >>>>>> >>>>>> All designed to be fully usable with just a touchscreen and simple >>>>>> to use. Runs happlily on an Eeetop..., image processing initially >>>>>> implemented in Smalltalk, optimised in Smalltalk then transcoded >>>>>> into Slang for a plugin. Sharpen filter taken from Diego's image >>>>>> processing library. Custom hardware support for Datalogic >>>>>> scanners, >>>>>> based around an asynchronous device framework developed in house >>>>>> for >>>>>> other projects (who say we can't get large-scale reuse!). Webcam >>>>>> support is also available (VideoForLinux plugin) if required, all >>>>>> customisable via configuration files (XML-based). >>>>>> >>>>>> Here's to all the dedicated Pharo users for helping to make this >>>>>> possible. >>>>>> >>>>>> Regards, Gary >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: Schwab,Wilhelm K >>>>>> To: Pharo-project(a)lists.gforge.inria.fr >>>>>> Sent: Friday, November 20, 2009 5:13 PM >>>>>> Subject: Re: [Pharo-project] Application screenshots >>>>>> >>>>>> >>>>>> Great, thanks, good luck, can't wait, etc. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>>>>> [mailto:pharo-project-bounces@lists.gforge.inria.fr >>>>>> ] On Behalf Of Gary Chambers >>>>>> Sent: Friday, November 20, 2009 11:54 AM >>>>>> To: Pharo Development >>>>>> Subject: [Pharo-project] Application screenshots >>>>>> >>>>>> >>>>>> Some coming for our (Pinesoft) first "shrink wrapped" product >>>>>> solution. Pharo based, of course ;-) >>>>>> >>>>>> Give me an hour or so, will be on my Flickr pages since given the >>>>>> go-ahead. >>>>>> >>>>>> Regards, Gary >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ > 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 Nicolas Cellier

2009/11/20 Igor Stasenko <siguctua(a)gmail.com>: > 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. >> Hi Igor > > 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'. > Just what [] box are currently :) but a bit more informative. Don't flame me, I don't support this feature as a reasonnable default. > 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? > +1 So I'm happy to notice you should agree on my modification for rendering linefeed transparently in trunk. > 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. > Good sense of logic, that's a smart demonstration. But we have to be pragmatic too. If we limit this feature to poor text editors (character files), the demonstration about rich text does not really apply. Be it an option or a separate tool does not really matter. Notepad++ and lot of other string editors have this as an option. As long as it is an option in FileList tool and not the main behaviour, I think you could tolerate it, couldn't you ? cheers Nicolas >>> 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. > > _______________________________________________ > 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 Nicolas Cellier

We must separate the matters. - how should we display the line-feed (independently from their source) - how should the FileList tool handle various conversions (line end, encodings,...) Old squeak and current Pharo both display an ugly [] box in case there is a line feed in a String. >From this point of view, displaying a boxed [lf] in Cuis is already a big progress :), though I did not follow the same path in trunk. Concerning the file tool, +100 for the reasonnable default behavior on read. But that should not be the sole option. For example, I have plenty of mixed line end conventions files. This is due to people editing the files in heterogeneous environments. You can judge that this is silly, I perfectly agree, but I can't fight. It just exists that's a fact. Once you admit that, the bad players are the applications not handling correctly these mixed conventions files. Squeak/Pharo are bad players when they try to smartly detectLineEndConvention, they are not smart at all and introduce spurious line breaks when they write back with same guessed convention. That's why I HAVE TO be able to CONTROL the read behaviour too, and not let smart tools decide for me. Transparent line end is one of the options. As noticed by Igor, same for encodings of course. As for the display, my opinion is that most of the time we just don't want to see the line endings. That's why I changed this in trunk to be transparent (more exactly as transparent if following a cr, as a line break otherwise) This enables to not care at all for converting external world input->image in most cases. I still have to care about converting image->output to external world, though, I think we all agree on that, so +100 too for the save as proposals (hehe, I also have some cases when I do not care at all, because I have a smart tool chain handling mixed conventions, so again transparent will be an option). In some particular situations we do care and wish to visually control the line ends. An hex editor is not that fine because we are speaking of text here, not binary data, and an hex editor generally fails to interpret the line breaks and leads to hardly readable data. I personnally use notepad++ and change a display parameter to show [cr] [lf] boxes. That's what Juan is addressing in Cuis, and I think it would be simple to incorporate this feature as another option in the file browser, so we could eventually do it. Anyway, I agree, not as the default behavior... All in all, I think we mostly agree, and should reach a consensus. cheers Nicolas 2009/11/20 Peter Hugosson-Miller <oldmanlink(a)gmail.com>: > 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 > > _______________________________________________ > 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] Application screenshots

by Adrian Lienhard

Do we have slightly more information than the link alone? E.g., a short description of the service and something about the company that provides the service? Adrian On Nov 20, 2009, at 21:55 , StÃ©phane Ducasse wrote: > Adrian > > you can put a link to www.ibizlog.com > :) > > Stef > On Nov 20, 2009, at 9:13 PM, Adrian Lienhard wrote: > >> I changed the image to the one you suggested below. >> >> Adrian >> >> On Nov 20, 2009, at 19:34 , Gary Chambers wrote: >> >>> Of course, the screenshot piccy is from our "Report Builder"... >>> though that >>> will be integrated into the "Enterprise" version for customisation >>> of the >>> relabels (Database/barcode integration etc.). More reuse coming for >>> that! >>> Thanks for the exposure though, perhaps change the pic to >>> http://www.flickr.com/photos/12018791@N06/4120335614/in/set-721576016593932… >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Adrian Lienhard" <adi(a)netstyle.ch> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Friday, November 20, 2009 6:25 PM >>> Subject: Re: [Pharo-project] Application screenshots >>> >>> >>>> Great, thanks for sharing! >>>> >>>> I added an entry to the top of >>>> http://www.pharo-project.org/about/success-stories >>>> >>>> If other companies like to get their Pharo project featured on the >>>> success stories page, please send me information. >>>> >>>> Cheers, >>>> Adrian >>>> >>>> >>>> On Nov 20, 2009, at 18:57 , Gary Chambers wrote: >>>> >>>>> Here for now: >>>>> http://www.flickr.com/photos/12018791@N06/sets/72157601659393251/ >>>>> >>>>> Some explanation... >>>>> >>>>> The application is designed to improve efficiency with relabelling >>>>> of packages/groups-of-packages within the logistics industry. >>>>> Often >>>>> the pre-existing labelling is hard to read and/or covered with >>>>> polywrap etc. >>>>> >>>>> MBagger provides a simple means of rescanning labels with >>>>> algorithmic clean-up suitable for re-printing with commerically >>>>> available thermal printers (1 bit per pixel) >>>>> >>>>> Sorry for "plug" bust some details here: >>>>> http://www.pinesoft.co.uk/what/logisticsproducts >>>>> >>>>> Certainly an interesting project. Leveraging the lean approach of >>>>> Pharo with the visual appeal of Polymorph. >>>>> >>>>> All designed to be fully usable with just a touchscreen and simple >>>>> to use. Runs happlily on an Eeetop..., image processing initially >>>>> implemented in Smalltalk, optimised in Smalltalk then transcoded >>>>> into Slang for a plugin. Sharpen filter taken from Diego's image >>>>> processing library. Custom hardware support for Datalogic >>>>> scanners, >>>>> based around an asynchronous device framework developed in house >>>>> for >>>>> other projects (who say we can't get large-scale reuse!). Webcam >>>>> support is also available (VideoForLinux plugin) if required, all >>>>> customisable via configuration files (XML-based). >>>>> >>>>> Here's to all the dedicated Pharo users for helping to make this >>>>> possible. >>>>> >>>>> Regards, Gary >>>>> >>>>> ----- Original Message ----- >>>>> From: Schwab,Wilhelm K >>>>> To: Pharo-project(a)lists.gforge.inria.fr >>>>> Sent: Friday, November 20, 2009 5:13 PM >>>>> Subject: Re: [Pharo-project] Application screenshots >>>>> >>>>> >>>>> Great, thanks, good luck, can't wait, etc. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>>>> [mailto:pharo-project-bounces@lists.gforge.inria.fr >>>>> ] On Behalf Of Gary Chambers >>>>> Sent: Friday, November 20, 2009 11:54 AM >>>>> To: Pharo Development >>>>> Subject: [Pharo-project] Application screenshots >>>>> >>>>> >>>>> Some coming for our (Pinesoft) first "shrink wrapped" product >>>>> solution. Pharo based, of course ;-) >>>>> >>>>> Give me an hour or so, will be on my Flickr pages since given the >>>>> go-ahead. >>>>> >>>>> Regards, Gary >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> _______________________________________________ >>> 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] CrLfStream bug.

by StÃ©phane Ducasse

On Nov 20, 2009, at 9:59 PM, Nicolas Cellier wrote: > 2009/11/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Thanks henrik and nicolas. >> this is cool to have you around. >> Software is so complex and life so short.... >> > > Tsss... It does not have to be complex, what Smalltalk was made for? ;) yes I dream about a system so nice that we could understand it alone. > Does it have to be short ? unfortunately I do not have the answer this time... > > Nicolas > >> Stef >> >> On Nov 20, 2009, at 8:50 PM, Nicolas Cellier wrote: >> >>> 2009/11/20 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>> 2009/11/20 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >>>>> Speaking of end of line conventions, here's issue 1472 :) >>>>> >>>>> CrLfStream fails horribly currently, since the UTF8-converters latin1map never gets initialized. >>>>> detectLineEndConvention gets called before converter is installed, and later on, >>>>> in MultiByteFileStream>>open: forWrite: , converter lineendings never gets set (and latin1map initialized) if lineEndConvention isn't nil. >>>>> >>>>> Alternatives: >>>>> >>>>> 1. ensure lineEndConvention installation: >>>>> >>>>> MultiByteFileStream>>open: fileName forWrite: writeMode >>>>> | result | >>>>> result := super open: fileName forWrite: writeMode. >>>>> result ifNotNil: [ >>>>> converter ifNil: [converter := UTF8TextConverter new]. >>>>> lineEndConvention ifNil: [ self detectLineEndConvention ] >>>>> ifNotNil: [self installLineEndConventionInConverter] >>>>> ]. >>>>> ^result >>>>> >>>>> 2. Use converter: instead, since that installs the lineEndConvention: >>>>> MultiByteFileStream>>open: fileName forWrite: writeMode >>>>> | result | >>>>> result := super open: fileName forWrite: writeMode. >>>>> result ifNotNil: [ >>>>> converter ifNil: [self converter: UTF8TextConverter new]. >>>>> lineEndConvention ifNil: [ self detectLineEndConvention ] >>>>> >>>>> ]. >>>>> ^result >>>>> >>>>> Ironically, if no lineEndConvention is defined, it will default to the same line-ending as you would get with a CrLfStream anyways :P >>>>> >>>>> I'm submitting a slice with approach 2 to inbox. >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>> >>>> >>>> Oh, I see now why I missed this one. >>>> trunk does not have Keith change: >>>> lineEndConvention ifNil: [ self >>>> detectLineEndConvention ] >>>> but a direct call to: >>>> self detectLineEndConvention >>>> So trunk always set the line end convention in the converter and I >>>> decided it was not necessary to use self converter: here... >>>> Integrating Keith change has broken this fragile constuction, don't >>>> know when it came in. >>> >>> http://code.google.com/p/pharo/issues/detail?id=1013 in 10400 >>> http://bugs.squeak.org/view.php?id=6086 >>> >>> Now I know >>> >>>> I approve solution 2) >>>> >>>> Cheers >>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > _______________________________________________ > 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