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

Re: [Pharo-dev] Support understanding changes

by Camillo Bruni

>> Indeed, some meta data is needed, although I think much of it can be properly inferred if the commits have sufficient resolution. As a side note, git for instance does not track renames: >> https://git.wiki.kernel.org/index.php/Git_FAQ#Why_does_Git_not_.22track.22_… >> http://permalink.gmane.org/gmane.comp.version-control.git/217 >> Specially the last link is worth reading ;) > > Yes, this seems probable, but we need to try to be sure. definitely, for now this sounds more like an optimization, sticking to the full metadata seems to be easier. >> If you attach the information to the commit itself that will be fine: >> https://www.kernel.org/pub/software/scm/git/docs/git-notes.html >> >> because, as you say, each time metadata ends up in the sources part of the git >> repository we will have merge problems, since you can only properly merge such >> data if you fully understand the semantic meaning. > > Hum. Reading git notes say that there is a merge operation involved... haha, yeah thought the same ;), though I never used notes, so I have to try that out first..

Nov. 6, 2013

Re: [Pharo-dev] Nautilus groups in 3.0

by phil＠highoctane.be

Give me the groups back. I hate that tree. Positively. On Wednesday, November 6, 2013, Benjamin wrote: > I personally do not like this feature, but I have been told to get it a > try :) > > Ben > > On 06 Nov 2013, at 12:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > > On Wed, Nov 6, 2013 at 8:46 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > In recent 3.0 Pharo images the Nautlilus browser shows packages and > groups in the same pane. Is this in general intended for the future or a > bug? > > feature :) > > > Also the Hierarchy button is layered above the "Groups" button. > Is this just a layout problem or will the "Groups" button be obsolete > anyway (see above)? > > is not on top, "groups" are removed (since now they are on top, no need > for a button). > > anyway if you do not feel confortable, feel free to propose any kind of > enhancement... this changes were made following the ideas behind a > screenshot Stef sent some weeks ago (I do not remember the topic exactly > now, but you will find it searching the history). > > > Thx > T. > > > > -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

Nov. 6, 2013

Re: [Pharo-dev] Support understanding changes

by Goubier Thierry

Le 06/11/2013 14:01, Camillo Bruni a Ã©crit : > > On 2013-11-06, at 13:38, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> >> >> Le 06/11/2013 13:20, StÃ©phane Ducasse a Ã©crit : >>> Now that we have epicea I would really love to have a tool that does not show me stupidly a diff but >>> take into account the actions that have been performed like rename class, splitâ¦. >> >> Yes! I want that too! How do we try EPICEA? Is it already integrated? >> >>> Side questions: camillo and other giter, I was thinking that it would make sense to publish on git metadata (may be in ston) >>> representing the semantics of the operation that led to the changes) so that tools can take advantage of this information >>> to present semantical operation instead of plain stupid diff. For example split this method, rename class,â¦. >> >> +100 > > Indeed, some meta data is needed, although I think much of it can be properly inferred if the commits have sufficient resolution. As a side note, git for instance does not track renames: > https://git.wiki.kernel.org/index.php/Git_FAQ#Why_does_Git_not_.22track.22_… > http://permalink.gmane.org/gmane.comp.version-control.git/217 > Specially the last link is worth reading ;) Yes, this seems probable, but we need to try to be sure. >> My approach would be to focus on tools in the Pharo world to explore that, at the Monticello GUI level (and merge tools). >> >> In the Git world, I'll focus simply on a file format able to store that knowledge, in a way which minimises git-induced conflicts... The goal being that a git merge would recreate a working Smalltalk result (no conflicts) with a correct EPICEA history (eventually recreated from the git stored data). >> >> What I know is that a single file in whatever format containing the EPICEA log will be a conflict magnet. > > If you attach the information to the commit itself that will be fine: > https://www.kernel.org/pub/software/scm/git/docs/git-notes.html > > because, as you say, each time metadata ends up in the sources part of the git > repository we will have merge problems, since you can only properly merge such > data if you fully understand the semantic meaning. Hum. Reading git notes say that there is a merge operation involved... I hope that a git merge can be done without touching at the notes, and then it becomes easy to rebuild the EPICEA history from scanning the git history and recovering the notes (and as long as we are not using MC approach to searching past versions, of course). I know I can make an equivalent proposal as a directory and files, i.e. not hidden in git notes (which makes it non-portable to other version control systems / non git). > Additionally I think, that the transition data should not go into the sources, > technically they are no sources, but they belong on the commit itself. I have no such limit :) And I suspect that in some formats (mcz), this metadata will have to appear as part of the source. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Nov. 6, 2013

extracting a pier book into pillar files

by Tudor Girba

Hi, Is there existing support to extract an existing Pier-based book into Pillar files? I would be interested in moving the Moose book to this format. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Nov. 6, 2013

Re: [Pharo-dev] Support understanding changes

by Camillo Bruni

On 2013-11-06, at 13:38, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 06/11/2013 13:20, StÃ©phane Ducasse a Ã©crit : >> Now that we have epicea I would really love to have a tool that does not show me stupidly a diff but >> take into account the actions that have been performed like rename class, splitâ¦. > > Yes! I want that too! How do we try EPICEA? Is it already integrated? > >> Side questions: camillo and other giter, I was thinking that it would make sense to publish on git metadata (may be in ston) >> representing the semantics of the operation that led to the changes) so that tools can take advantage of this information >> to present semantical operation instead of plain stupid diff. For example split this method, rename class,â¦. > > +100 Indeed, some meta data is needed, although I think much of it can be properly inferred if the commits have sufficient resolution. As a side note, git for instance does not track renames: https://git.wiki.kernel.org/index.php/Git_FAQ#Why_does_Git_not_.22track.22_… http://permalink.gmane.org/gmane.comp.version-control.git/217 Specially the last link is worth reading ;) > My approach would be to focus on tools in the Pharo world to explore that, at the Monticello GUI level (and merge tools). > > In the Git world, I'll focus simply on a file format able to store that knowledge, in a way which minimises git-induced conflicts... The goal being that a git merge would recreate a working Smalltalk result (no conflicts) with a correct EPICEA history (eventually recreated from the git stored data). > > What I know is that a single file in whatever format containing the EPICEA log will be a conflict magnet. If you attach the information to the commit itself that will be fine: https://www.kernel.org/pub/software/scm/git/docs/git-notes.html because, as you say, each time metadata ends up in the sources part of the git repository we will have merge problems, since you can only properly merge such data if you fully understand the semantic meaning. Additionally I think, that the transition data should not go into the sources, technically they are no sources, but they belong on the commit itself.

Nov. 6, 2013

Re: [Pharo-dev] Support understanding changes

by StÃ©phane Ducasse

> >>> In the Git world, I'll focus simply on a file format able to store that knowledge, in a way which minimises git-induced conflicts... The goal being that a git merge would recreate a working Smalltalk result (no conflicts) with a correct EPICEA history (eventually recreated from the git stored data). >>> >>> What I know is that a single file in whatever format containing the EPICEA log will be a conflict magnet. >> >> Why conflicting we will change it systematically. > > Because if you merge with git, then you will get conflicts and those will be a pain to fix. may be they should be ignore while merging but we cannot compute them from git because there are semantics information so if in the future we want to use fully git we will have to have a solution. But for now indeed we should focus on putting that info in MCZ > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Nov. 6, 2013

Re: [Pharo-dev] Peek

by Sven Van Caekenberghe

On 06 Nov 2013, at 13:29, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 06 Nov 2013, at 10:38 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> BTW, do we still need UTF16 support ? >> >> For those encodings that we still want to support in the future, we should have new and more principled implementations under ZnCharacterEncoder. That is, if we ever want to fase out TextConverter. > > UTF16 is the encoding for string arguments to the Unicode-aware version of the Windows API's, so Iâd say yes. > Not too sure about JNI, but I know Java also uses UTF16 internally. > > So the short answer is yes. > Not as a storage encoding, but for calling foreign functions, itâs quite important. Ah, OK. Fancy giving it a try, to create a ânewâ implementation under ZnCharacterEncoder with some tests ? There are only 3 abstract methods to implement, if you should already know UTF16, it would not be too much work ;-) > Cheers, > Henry >

Nov. 6, 2013

Re: [Pharo-dev] Peek

by Sven Van Caekenberghe

On 06 Nov 2013, at 13:20, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On 04 Nov 2013, at 5:12 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> Well, I just realised that ZnCharacterReadStream and ZnCharacterWriteStream did not yet make use of the optimisations that I did for ZnCharacterEncoding some time ago. More specifically, they were not yet using #next:putAll:startingAt:toStream: and #readInto:startingAt:count:fromStream: which are overwritten for ZnUTF8Encoder with (super hacked) versions that assume most of the input will be ASCII (a reasonable assumption). >> >> I am still chasing a bug, but right now: >> >> [ (ZnCharacterReadStream on: ('timezones.json' asFileReference readStream binary)) >> next: 65536; close ] bench. >> >> "135 per second.â BEFORE >> "3,310 per second.â AFTER >> >> But of course the input file is ASCII, so YMMV. >> >> Iâll let you know when I commit this code. >> >> Sven > > Yeahâ¦ sooo, I loaded the updated version, great improvement for streams on Latin1 content :D > > Maybe itâs just me, but I tested with actual wide source as well (it was as slow as youâd expect), and I think you need a notQuiteSoOptimizedReadInto* which uses the normal Byte -> Wide become: conversion machinery. > Writing a ZnByteStringBecameWideString handler for every next: (and cousins) call where source may be non-latin1 is a real chore/nasty surprise for those used to dealing with legacy streams/converters... > You can sort of kinda make up for the performance hit (at least on these sizes) with a faster replace:from:to:with:startingAt: in use after the fact, by using basicAt:put: to the string, thus avoiding converting the replacement value to character. > > Cheers, > Henry > > PS: Why is ZnByteStringBecameWideString a notification and not a resumable exception? I would assume those who run into it without a handler would rather have an actual error, than a result where their string has been read up to the first wide charâ¦ Henrik, thanks again for the feedback, it is really useful. You are right, the ZnByteStringBecameWideString hack was introduced specifically to avoid the become, because benchmarking showed that it took too long. The original user is ZnStringEntity>>#readFrom: Now, if you know up front that your string will be wide anyway, then there is #decodeBytesIntoWideString: Yes, ZnByteStringBecameWideString should probably be a resumable exception, as not handling it properly will lead to errors. I will have to think and reconsider the generality/specificity of the optimisation hack in ZnUTF8Encoder. I got some ideas, but it will take some time. At least the code works now, time to process the constructive criticism. Regards, Sven

Nov. 6, 2013

Re: [Pharo-dev] Support understanding changes

by Goubier Thierry

Le 06/11/2013 13:39, StÃ©phane Ducasse a Ã©crit : > > On Nov 6, 2013, at 1:38 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> >> >> Le 06/11/2013 13:20, StÃ©phane Ducasse a Ã©crit : >>> Now that we have epicea I would really love to have a tool that does not show me stupidly a diff but >>> take into account the actions that have been performed like rename class, splitâ¦. >> >> Yes! I want that too! How do we try EPICEA? Is it already integrated? > > Martin did not send a public mail to the list? > Shame on him :) > >>> Side questions: camillo and other giter, I was thinking that it would make sense to publish on git metadata (may be in ston) >>> representing the semantics of the operation that led to the changes) so that tools can take advantage of this information >>> to present semantical operation instead of plain stupid diff. For example split this method, rename class,â¦. >> >> +100 >> >> My approach would be to focus on tools in the Pharo world to explore that, at the Monticello GUI level (and merge tools). > > Yes you are right. > But people now use git to browse changes and it only work for little edition. > But you are right. I would like also to have that combined with Torch because the Torch visualziation was so great. My proposal should offer both: see all operations with git without conflicts when merging / cherry picking, whatever. And let Pharo present more advanced views on the development history. >> In the Git world, I'll focus simply on a file format able to store that knowledge, in a way which minimises git-induced conflicts... The goal being that a git merge would recreate a working Smalltalk result (no conflicts) with a correct EPICEA history (eventually recreated from the git stored data). >> >> What I know is that a single file in whatever format containing the EPICEA log will be a conflict magnet. > > Why conflicting we will change it systematically. Because if you merge with git, then you will get conflicts and those will be a pain to fix. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Nov. 6, 2013

Re: [Pharo-dev] Peek

by Camillo Bruni

that would be called XStreams, no? On 2013-11-06, at 13:43, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi henrik > > why don't you give a try to change our lives and propose a new MultuByteFileStream and friends :) > > Stef > > >> That's great! >> Remembering that commit message was part of the reason for benching, was sort of disappointed there was no significant difference between Zn in 2.0 and latest 3.0... >> >> I guess with the amount of hacks accumulating, it is indeed turning into a worthy successor of MultiByteFileStream ;) >> >> Cheers, >> Henry >> >> P.S: If you want another delightful one in the same vein (both from WTFy-ness and perf improvement POV), take a gander at UTF16TextConverter >> nextPutByteString:toStream: >> >> >> On Mon, Nov 4, 2013 at 5:12 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Hi Henrik, >> >> Great writeup, thanks ! >> >> (more inline) >> >> On 04 Nov 2013, at 11:58, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >> > On 04 Nov 2013, at 9:57 , Diego Lont <diego.lont(a)delware.nl> wrote: >> > >> >> Working on Petit Delphi we found a strange implementation for asPetitStream: >> >> Stream>asPetitStream >> >> ^ self contents asPetitStream >> >> >> >> Further investigation showed that the basic peek was not fast enough for Petit Parser, as it is used a lot. So it implemented a "improved unchecked peek": >> >> PPStream>peek >> >> "An improved version of peek, that is slightly faster than the built in version." >> >> ^ self atEnd ifFalse: [ collection at: position + 1 ] >> >> >> >> PPStream>uncheckedPeek >> >> "An unchecked version of peek that throws an error if we try to peek over the end of the stream, even faster than #peek." >> >> ^ collection at: position + 1 >> >> >> >> But in my knowledge a basic peek should be fast. The real problem is the peek in the underlying peek: >> >> PositionableStream>peek >> >> "Answer what would be returned if the message next were sent to the >> >> receiver. If the receiver is at the end, answer nil." >> >> >> >> | nextObject | >> >> self atEnd ifTrue: [^nil]. >> >> nextObject := self next. >> >> position := position - 1. >> >> ^nextObject >> >> >> >> That actually uses "self next". The least thing one should do is to cache the next object. But isn't there a primitive for peek in a file stream? Because al overriding peeks of PositionableStream have basically the same implementation: reading the next and restoring the state to before the peek (that is slow). So we would like to be able to remove PPStream without causing performance issues, as the only added method is the "improved peek". >> >> >> >> Stephan and Diego >> > >> > If you are reading from file, ZnCharacterStream should be a valid alternative. >> > If not, ZnBufferedReadStream on an internal collection stream also does peek caching. >> > >> > Beware with files though; itâs better to bench the overall operation for different alternatives. >> > F.ex, ZnCharacterStream is much faster than the standard Filestream for peek: >> > >> > cr := ZnCharacterReadStream on: 'PharoDebug.log' asFileReference readStream binary. >> > [cr peek] bench. '49,400,000 per second.' >> > cr close. >> > >> > FileStream fileNamed: 'PharoDebug.log' do: [:fs | [fs peek] bench] '535,000 per second.â >> > >> > but has different bulk reads characteristics (faster for small bulks, slower for large bulks, crossover-point at around 1k chars at once); >> > (The actual values are of course also dependent on encoder/file contents, those given here obtained with UTF-8 and a mostly/all ascii text file) >> > >> > [cr := ZnCharacterReadStream on: ('PharoDebug.log' asFileReference readStream binary ) readStream. >> > cr next: 65536; close] bench '105 per second.' '106 per second.â >> >> Well, I just realised that ZnCharacterReadStream and ZnCharacterWriteStream did not yet make use of the optimisations that I did for ZnCharacterEncoding some time ago. More specifically, they were not yet using #next:putAll:startingAt:toStream: and #readInto:startingAt:count:fromStream: which are overwritten for ZnUTF8Encoder with (super hacked) versions that assume most of the input will be ASCII (a reasonable assumption). >> >> I am still chasing a bug, but right now: >> >> [ (ZnCharacterReadStream on: ('timezones.json' asFileReference readStream binary)) >> next: 65536; close ] bench. >> >> "135 per second.â BEFORE >> "3,310 per second.â AFTER >> >> But of course the input file is ASCII, so YMMV. >> >> Iâll let you know when I commit this code. >> >> Sven >> >> > [FileStream fileNamed: 'PharoDebug.log' do: [:fs | fs next: 65536] >> > ] bench '176 per second.â >> > >> > If you use a StandardFilestream set to binary ( which has less overhead for binary nextâs compared to the MultiByteFileStream returned by asFileReference readStream)as the base stream instead, , the same general profile holds true, but with a crossover around 2k characters. >> > >> > TL;DR: Benchmark the alternatives. The best replacement option depends on your results. Appropriately (according to source and actual use) set up Zn-streams are probably your best bet. >> > >> > Cheers, >> > Henry >> >> >> >

Nov. 6, 2013