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

Re: [Pharo-project] Fwd: [squeak-dev] [ANN] Filesystem 1.0

by StÃ©phane Ducasse

so mike we should have the code else it will never happen. Stef On Nov 21, 2009, at 1:08 PM, Michael Rueger wrote: > Michael Rueger wrote: > >> quite a bit of inspiration on how to use of URIs. > > how to *improve* the use of URIs > :-) > > Michael > > > _______________________________________________ > 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

[Pharo-project] Issue 332: (Arithmetic protocol should be removed from Collections and Strings)

by Simon Denier

Hi there from Pharo sprint We are trying to tackle Issue 332: (Arithmetic protocol should be removed from Collections and Strings) The problem is that the chronology classes in Pharo depend on the arithmetic of Collection to perform time computation. So there is two things. We remove the Collection-arithmetic from Core and we propose: - move the Colllection arithmetic stuff in an extension package, so that if people want to use it, they can - rewrite the Chrono stuff so that they do their computation without Collection arithmetics. -- Simon

Nov. 21, 2009

[Pharo-project] [update 1.1] #11054

by StÃ©phane Ducasse

Hola from Buenos Ares Some issues integrated.... :) 11054 ----- - Issue 1483: Fix: remove all methods with "etoy" in its name - Issue 810: Preference to settings refactoring: #annotationPanes case - Issue 1480: should remove the current Setting package

Nov. 21, 2009

Re: [Pharo-project] Fwd: [squeak-dev] [ANN] Filesystem 1.0

by Michael Rueger

Michael Rueger wrote: > quite a bit of inspiration on how to use of URIs. how to *improve* the use of URIs :-) Michael

Nov. 21, 2009

Re: [Pharo-project] Fwd: [squeak-dev] [ANN] Filesystem 1.0

by Michael Rueger

StÃ©phane Ducasse wrote: > - I would really like to see how we can get rid of FileDirectory and use your lib and its improved version. <broken record> by adding a handful of convenience methods almost everything can be done with URIs already. </broken record> Having gotten that out of the way ;-) I think your library provides quite a bit of inspiration on how to use of URIs. And I totally agree that we need to rewrite/replace the current file/dictionary implementation. Michael

Nov. 21, 2009

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

by Adrian Lienhard

Hi Dave, [...] > The remaining issue that is relevant to the Pharo image (as opposed to > OSProcess running on any other image) is this CommandShellTestCase > issue. I'm not sure about this anymore. I just ran CommandShellTestCase a couple of times in a Squeak trunk image and the third time it also blocked on completionSemaphore. Do you see different problems on Linux? > 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. That would certainly be a good next step! Cheers, Adrian [...]

Nov. 21, 2009

Re: [Pharo-project] Fwd: [squeak-dev] [ANN] Filesystem 1.0

by StÃ©phane Ducasse

Hi colin good that you did that because I was starting to do the same. This file stuff was too frustrating. - I read the tutorial and I scanned the code (too early this morning) and I could not see how to rename a file. without copying it. - why having this in the tests and not in the classes? createDirectory: aString filesystem createDirectory: (filesystem stringToPath: aString) createFile: aString filesystem createFile: (filesystem stringToPath: aString) - It was not clear to me how we map the old interface readyOnlyFileNamed and friends - ref := FSWindowsFilesystem stringToReference: 'D:\Squeak\3.10'. I was wondering if reference should be part of the user domain because why not ref := FSWindowsFilesystem on: 'D:\Squeak\3.10'. or ref := FSWindowsFilesystem folder: 'D:\Squeak\3.10'. I was confused by FSReference vs. FSPath - I would really like to see how we can get rid of FileDirectory and use your lib and its improved version. On Nov 21, 2009, at 10:01 AM, Lukas Renggli wrote: > ---------- Forwarded message ---------- > From: Colin Putney <cputney(a)wiresong.ca> > Date: 2009/11/21 > Subject: [squeak-dev] [ANN] Filesystem 1.0 > To: The general-purpose Squeak developers list > <squeak-dev(a)lists.squeakfoundation.org> > > > Hi folks, > > I've just made available for download a new project of mine. It's an > alternative interface to the filesystem, which grew out of my > frustration with trying to use FileDirectory for some particularly > file-intensive code. It's built upon the FilePlugin primitives, but > all the image-side code is written from scratch. > > The interface offers: > - Convenient path manipulation > - Transparent access to the contents of zip files > - Late-bound references to files and directories > - Support for working with entire directory trees > > A SAR file is available for download here: > > http://www.wiresong.ca/downloads/Filesystem-1.0.0.sar > > A short tutorial is available here: > > http://www.wiresong.ca/filesystem/ > > Feedback appreciated! > > Colin > > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > 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] Issue 1424 in pharo: Comparing a MethodProperties analogousCodeTo: an AdditionalMethodState is broken

by Marcus Denker

On Nov 20, 2009, at 9:57 PM, stephane ducasse wrote: > > > Begin forwarded message: > >> From: pharo(a)googlecode.com >> Date: November 20, 2009 8:08:46 PM GMT+01:00 >> To: stephane.ducasse(a)gmail.com >> Subject: Re: Issue 1424 in pharo: Comparing a MethodProperties analogousCodeTo: an AdditionalMethodState is broken >> >> >> Comment #10 on issue 1424 by nicolas.cellier.aka.nice: Comparing a MethodProperties analogousCodeTo: an AdditionalMethodState is broken >> http://code.google.com/p/pharo/issues/detail?id=1424 >> >> I mean you should >> - correct ScriptLoader>>#cleanUpMethods >> - then execute (ScriptLoader new cleanUpMethods) in an update stream to get rid of >> these old MethodProperties Ok, so the #cleanUpMethods is broken right now. And there is a problem with some Service thing holding on a method. (we need reset Services in cleanUpMethods, too). >> >> Then remove or deprecate MethodProperties (classify in backward compatibility or >> something...). >> Don't know if you can simply remove it, or if some binary file outs of CompiledMethod >> require it. Ask Marcus. No, properties where used just internally for Pragmas. And those work. The other use of properties was in Persephone/Reflectivity (http://scg.unibe.ch/research/reflectivity) and in Bytesurgeon (http://scg.unibe.ch/research/bytesurgeon) Both of which will need some change (fort the better!) to work on Pharo anyway. So no problem. We should remove MethodProperty. I will add report to the tracker for this. Marcus -- Marcus Denker -- http://www.marcusdenker.de

Nov. 21, 2009

[Pharo-project] Fwd: [squeak-dev] [ANN] Filesystem 1.0

by Lukas Renggli

---------- Forwarded message ---------- From: Colin Putney <cputney(a)wiresong.ca> Date: 2009/11/21 Subject: [squeak-dev] [ANN] Filesystem 1.0 To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Hi folks, I've just made available for download a new project of mine. It's an alternative interface to the filesystem, which grew out of my frustration with trying to use FileDirectory for some particularly file-intensive code. It's built upon the FilePlugin primitives, but all the image-side code is written from scratch. The interface offers: Â Â Â Â - Convenient path manipulation Â Â Â Â - Transparent access to the contents of zip files Â Â Â Â - Late-bound references to files and directories Â Â Â Â - Support for working with entire directory trees A SAR file is available for download here: Â Â Â Â http://www.wiresong.ca/downloads/Filesystem-1.0.0.sar A short tutorial is available here: Â Â Â Â http://www.wiresong.ca/filesystem/ Feedback appreciated! Colin -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 21, 2009

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