- Pharo-users - lists.pharo.org

Re: [Pharo-users] Cleaning changes file?

by Thierry Goubier

2015-03-10 9:28 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > > But stiil, the changes allow you a recovery in case of a crash. It has > some valuables side effects. > > > > Yes, it was genius to merge both source storage and transaction log 30 > years ago... today we would > not do that. > Wouldn't we? Or would we do a more compact log format, optimizing by the knowledge of what is in the image and what is inside the package repositories? i.e. I'm not sure that the fundamental is wrong. Just that the environment is a bit different. I toyed a long time ago with the idea of having a git as a replacement of the changes. On every method change, you commit... Has a way of compacting by itself the changes. Largely overkill :) Now, I could also see a scheme based on MC, where the source of a method is fetched from the package (with an ast cache, if needed). Not very difficult to do. But it's not very grandiose. Just a bit of software engineering. Not interesting ;) Thierry

March 10, 2015

Re: [Pharo-users] Cleaning changes file?

by Marcus Denker

> > But stiil, the changes allow you a recovery in case of a crash. It has some valuables side effects. > Yes, it was genius to merge both source storage and transaction log 30 years agoâ¦ today we would not do that. Marcus

March 10, 2015

Re: [Pharo-users] Cleaning changes file?

by Marcus Denker

> On 10 Mar 2015, at 09:21, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > Hi Marcus, > > Speaking of .changes and .source files, I remember a mid-term goal of introducing them inside the image. > This would imply only one file (.image) and not so much space wasted IIRC an experiment (done by Camillo?) where it was zipped on the fly. > Am just wondering if this is still a goal? > Yes, but the devil is in the detailsâ¦ e.g. just compressing per method is not good enough, we need to share the compression dictionary. Another interesting thing is that we have the symbols already in the system, thus we do not need to store all those strings again. Of course my dream would be some AST-like representation that is a) compressed (decompressed on the fly) and good enough to present a text view to the human. Marcus

March 10, 2015

Re: [Pharo-users] Cleaning changes file?

by Thierry Goubier

2015-03-10 7:58 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 10 Mar 2015, at 07:36, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Laura, > > > > You can do that using the expression: > > > > PharoChangesCondenser condense > > > > Although that also means you lose the version history of methods inside > your image. This is typically not done a lot, maybe for production deploy, > maybe for release of Pharo itself. > > > > > Yes, but we need to change that. The artefact on the CI server needs to be > the artefact of release. We should not have *anything* of the kind "and a > day before release we call X". > Because for sure it will be broken. And we waste resources: the changes > are the history of the revision control system. > > The current system has multiple problems: > > - Why have them *in addition* in a file on disk of everyone even though > almost nobody will ever look at them? > - We have to maintain two history mechanisms. Hard to explain: "Yes, > version of a method does not show you the version to committed when you use > a new image". WTF? > - It does not scale. We clear the history between releases as the > .changes get too large. So the practical use of the history is not very high > And getting lower and lower with repositories where one can query for the history of a method, such as gitfiletree. > - handling .sources, .changes and .sources is complex and hard to explain > - It is *SLOW*. Reading code from .sources/.changes is amazingly slow > - The code implementing all this is amazingly bad. Just look at the > references to SourceFiles: 44 references, all over the place. > And where it could be reused, such as for doIts, a new mechanism with on disk files is created to store source code: the GTPlayground cache :( But stiil, the changes allow you a recovery in case of a crash. It has some valuables side effects. Thierry

March 10, 2015

Re: [Pharo-users] Cleaning changes file?

by Luc Fabresse

Hi Marcus, Speaking of .changes and .source files, I remember a mid-term goal of introducing them inside the image. This would imply only one file (.image) and not so much space wasted IIRC an experiment (done by Camillo?) where it was zipped on the fly. Am just wondering if this is still a goal? Luc 2015-03-10 7:58 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 10 Mar 2015, at 07:36, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Laura, > > > > You can do that using the expression: > > > > PharoChangesCondenser condense > > > > Although that also means you lose the version history of methods inside > your image. This is typically not done a lot, maybe for production deploy, > maybe for release of Pharo itself. > > > > > Yes, but we need to change that. The artefact on the CI server needs to be > the artefact of release. We should not have *anything* of the kind âand a > day before release we call Xâ. > Because for sure it will be broken. And we waste resources: the changes > are the history of the revision control system. > > The current system has multiple problems: > > - Why have them *in addition* in a file on disk of everyone even though > almost nobody will ever look at them? > - We have to maintain two history mechanisms. Hard to explain: âYes, > version of a method does not show you the version to committed when you use > a new imageâ. WTF? > - It does not scale. We clear the history between releases as the > .changes get too large. So the practical use of the history is not very high > - handling .sources, .changes and .sources is complex and hard to explain > - It is *SLOW*. Reading code from .sources/.changes is amazingly slow > - The code implementing all this is amazingly bad. Just look at the > references to SourceFiles: 44 references, all over the place. > > > Marcus >

March 10, 2015

Re: [Pharo-users] Cleaning changes file?

by Marcus Denker

> On 10 Mar 2015, at 07:36, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Laura, > > You can do that using the expression: > > PharoChangesCondenser condense > > Although that also means you lose the version history of methods inside your image. This is typically not done a lot, maybe for production deploy, maybe for release of Pharo itself. > > Yes, but we need to change that. The artefact on the CI server needs to be the artefact of release. We should not have *anything* of the kind âand a day before release we call Xâ. Because for sure it will be broken. And we waste resources: the changes are the history of the revision control system. The current system has multiple problems: - Why have them *in addition* in a file on disk of everyone even though almost nobody will ever look at them? - We have to maintain two history mechanisms. Hard to explain: âYes, version of a method does not show you the version to committed when you use a new imageâ. WTF? - It does not scale. We clear the history between releases as the .changes get too large. So the practical use of the history is not very high - handling .sources, .changes and .sources is complex and hard to explain - It is *SLOW*. Reading code from .sources/.changes is amazingly slow - The code implementing all this is amazingly bad. Just look at the references to SourceFiles: 44 references, all over the place. Marcus

March 10, 2015

Re: [Pharo-users] Cleaning changes file?

by Sven Van Caekenberghe

Laura, You can do that using the expression: PharoChangesCondenser condense Although that also means you lose the version history of methods inside your image. This is typically not done a lot, maybe for production deploy, maybe for release of Pharo itself. Sven > On 10 Mar 2015, at 05:49, Laura Risani <laura.risani(a)gmail.com> wrote: > > Hi all, > > Can/should the changes file be somehow cleaned? > How do you recommend doing so? > > Love, > Laura

March 10, 2015

Re: [Pharo-users] Native language support

by Nick Doodka

Hello Marcus. Your patch solves my problem with capital letters. But it raises another trouble - every mouse wheel move or keyboard shortcut like ctrl+key cause next error MessageNotUnderstood:Character>>isArrow. 2015-03-07 12:39 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > I got a mail that suggest a fix: > > https://pharo.fogbugz.com/f/cases/15085/non-english-character-input > (I have attached it as a file-out, you can just drag-n-drop it on the pharo > desktop) > > We should check if that solves the problem. > > On Wed, Mar 4, 2015 at 10:37 AM, Nick Doodka <nickdoodka(a)gmail.com> wrote: > >> Hi all. >> I would like to use Pharo in my native language (Ukrainian in my case or >> Cyrillic), but I cannot enter some capital letters to Workspace / System >> Browser because it's fails on letters: CapsLock or Shift+<Keys> -> >> [~YGJK"V]. >> That behavior take place only in Pharo ver. 3 and 4. In Pharo 2.0 all >> keys working good! What is wrong? Platform - Windows XP >> >> > > > -- > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de >

March 10, 2015

Re: [Pharo-users] textsearch in pharo (was: GSoC mentor assistance for FOSSASIA smalltalk projects please)

by Martin BÃ¤hr

Excerpts from Martin BÃ¤hr's message of 2015-03-10 06:35:00 +0100: > Excerpts from stepharo's message of 2015-03-08 21:06:46 +0100: > > You should have a look at te project made by benjamin Areski because > > with camillo they developed > > a textsearch to searh the entire pharo image fast. > > can you give a link please? > i could not find anything on google. found it: http://smalltalkhub.com/#!/~BenjA/FullTextSearch thank you! greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

March 10, 2015

textsearch in pharo (was: GSoC mentor assistance for FOSSASIA smalltalk projects please)

by Martin BÃ¤hr

Excerpts from stepharo's message of 2015-03-08 21:06:46 +0100: > You should have a look at te project made by benjamin Areski because > with camillo they developed > a textsearch to searh the entire pharo image fast. can you give a link please? i could not find anything on google. greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

March 10, 2015