March 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About inspectors

by Tudor Girba

Thanks, Alex. I showed the above demo to non-Smalltalk developers with the idea of positioning Pharo/Moose as a one-stop-tool-for-all-sorts-of-analyses (I also showed them file manipulation). By the look in their eyes (they know the real pain of having poor and incomplete tools), I am pretty convinced that this is a significant opportunity that Pharo should take. Doru On Sat, Mar 8, 2014 at 1:13 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > Indeed having particular views is only one (minor) aspect. The coding and > navigation flow GTTools offers is fantastic. > I am not a big fan of Glamour scripting language, but what is built on top > of it is remarkable. It may even be a killing app for Pharo. > > Alexandre > > Le 08-03-2014 Ã 4:16, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > > I hope not. What are we trying to optimize? > > If you look closely at the GT work, you might notice that it is not just a > tool, it's a whole new philosophy for coding. The EyeInspector picked only > one aspect out of a whole. > > One high goal is to change programming such that the inspector + debugger > to capture most of the coding experience. This is what live means. Right > now, in the default Pharo we only code small things in the debugger and > nothing in the inspector. We work on the idea of a moldable IDE that will > change all that. > > Let's look at some facts. Right now, in my image I have 75 different > extensions for GTInspector. And the total amount of lines of code has > barely passed 1000 LOC (including all utility code). These are not just > independent views, but they are combinable. The amount of use cases > supported span a wide range: querying source code, visualizing performance, > navigating file system, querying DB, and more (read the posts from > humane-assessment.com for hints in this direction). > > We programmed most of these extensions from within the inspector both > because it's fun and because it's significantly more productive. And I am > not the only one. This power is not serendipity, it's by design. And we > only started to untap this potential. > > There is still a long way for the concept of inspector and I believe there > is a large payoff in it, too. > > Optimizing for a small thing now should not be the way to go :) > > Cheers, > Doru > > > > > On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > >> Well I would hope that some kind of convergence would be possible in the >> future. Maybe some kind of abstract meta description like magritte, that >> different tools can use. >> >> On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> > Hi everyone. >> > >> > This day I've attended Moose dojo and I'm pretty impressed with the >> possibilities of GTInspector. The one thing that I've noticed is that both >> GTInspactor and EyeInspector support custom inspections for objects. I'm >> wandering if we can come up with a common protocol to give an object >> specific infector view, and not develop a separate thing for each inspector. >> > >> > Uko >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > -- www.tudorgirba.com "Every thing has its own flow"

March 9, 2014

Re: [Pharo-dev] About inspectors

by Tudor Girba

Thanks for the interest. I added now a new blog post in which I detail an investigation scenario of a Postgres DB with the GTInspector: http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-… The post includes a video that kind of gets you through the most important parts: - use the playground - query the DB and preview the results through dedicated presentations - navigate through objects and code to learn the API - build a visualization in place and continue exploration - extend the inspector with a dedicated presentation Please let me know what you think. Cheers, Doru On Sat, Mar 8, 2014 at 8:48 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > Doru, > > Where to look on your blog for a view on the essentials of this? I see > http://www.humane-assessment.com/blog/making-the-pharo-settings-browser-ope… example. A video? > > I look at the blog and vids but it is a bit hard to find a basic demo to > grasp things. > > TIA > Phil > > > On Sat, Mar 8, 2014 at 8:16 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> I hope not. What are we trying to optimize? >> >> If you look closely at the GT work, you might notice that it is not just >> a tool, it's a whole new philosophy for coding. The EyeInspector picked >> only one aspect out of a whole. >> >> One high goal is to change programming such that the inspector + debugger >> to capture most of the coding experience. This is what live means. Right >> now, in the default Pharo we only code small things in the debugger and >> nothing in the inspector. We work on the idea of a moldable IDE that will >> change all that. >> >> Let's look at some facts. Right now, in my image I have 75 different >> extensions for GTInspector. And the total amount of lines of code has >> barely passed 1000 LOC (including all utility code). These are not just >> independent views, but they are combinable. The amount of use cases >> supported span a wide range: querying source code, visualizing performance, >> navigating file system, querying DB, and more (read the posts from >> humane-assessment.com for hints in this direction). >> >> We programmed most of these extensions from within the inspector both >> because it's fun and because it's significantly more productive. And I am >> not the only one. This power is not serendipity, it's by design. And we >> only started to untap this potential. >> >> There is still a long way for the concept of inspector and I believe >> there is a large payoff in it, too. >> >> Optimizing for a small thing now should not be the way to go :) >> >> Cheers, >> Doru >> >> >> >> >> On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: >> >>> Well I would hope that some kind of convergence would be possible in the >>> future. Maybe some kind of abstract meta description like magritte, that >>> different tools can use. >>> >>> On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>> > Hi everyone. >>> > >>> > This day I've attended Moose dojo and I'm pretty impressed with the >>> possibilities of GTInspector. The one thing that I've noticed is that both >>> GTInspactor and EyeInspector support custom inspections for objects. I'm >>> wandering if we can come up with a common protocol to give an object >>> specific infector view, and not develop a separate thing for each inspector. >>> > >>> > Uko >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

March 9, 2014

Crashing the vm in a reproducible way

by Pharo4Stef

Hi We already experienced this with Pavel in December. Once I loaded UnReloader from SystemConfigurations from STHUB/Pharo and I run unload I crash systematically the latest vm obtain with wget -O - http://get.pharo.org/30+vmLatest | bash the method crashing the system is checkState "self new checkState" | difference | difference := SystemNavigation default allUnimplementedCalls copyWithoutAll: unimplementedCalls. difference ifNotEmpty: [ self log nextPutAll: 'new unimplemented calls: '; cr; nextPutAll: difference asString; cr.]. difference := (SystemNavigation default obsoleteClasses collect: #name) asSet copyWithoutAll: obsoleteClasses. difference ifNotEmpty: [ self log nextPutAll: 'new obsoleteClasses:'; cr; nextPutAll: difference asString; cr]. difference := (Undeclared collect: #name) asSet copyWithoutAll: undeclared. difference ifNotEmpty: [ self log nextPutAll: 'new undeclared: '; cr; nextPutAll: difference asString; cr]. unimplementedCalls := SystemNavigation default allUnimplementedCalls. obsoleteClasses := (SystemNavigation default obsoleteClasses collect: #name) asSet. undeclared := (Undeclared collect: #name) asSet. Now executing the expressions one by one once the tools have been removed does not crash. Stef

March 9, 2014

Re: [Pharo-dev] Is there some shared memory space?

by Max Leske

Solve. Neither image nor VM nor Fuel luckily :) Cheers, Max On 08.03.2014, at 23:15, Max Leske <maxleske(a)gmail.com> wrote: > > On 08.03.2014, at 23:12, btc(a)openInWorld.com wrote: > >> Max Leske wrote: >>> >>> >>> On 08.03.2014, at 15:03, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> >>>> Hmm, as far as I know there is no "shared memory space"... or bah.. what do you mean by that? >>>> >>>> From my understanding I'd say that when you do: >>>> >>>> "- I fix the bug (i.e., commenting the self error)" >>>> >>>> you introduce some side effect that causes an infinite recursion => lots of contexts are reified because the vm stack gets full => you run out of memory >>> >>> No, it seems that the error lies with Fuel, although I canât yet say why. Iâm still investigating. >>> >>> Max >> >> Max, You've been able to reproduce the problem? > > Not really. Iâm working on it with Roberto and post back once weâve figured out more. Iâm pretty sure though that VM and image are fine (apart from limiting the heap size to 500MB *grml*). > > >> >>> >>>> >>>> BTW, are you on windows, linux, mac? which vm/image? >>>> >>>> Guille >>>> >>>> >>>> On Sat, Mar 8, 2014 at 2:55 PM, roberto.minelli(a)usi.ch <roberto.minelli(a)usi.ch> wrote: >>>> Anyone on this? It is very frustrating for me. >>>> >>>> Cheers, >>>> Roby >>>> >>>> On Mar 7, 2014, at 1:05 PM, roberto.minelli(a)usi.ch wrote: >>>> >>>> > >>>> > On Mar 7, 2014, at 12:24 PM, Max Leske <maxleske(a)gmail.com> wrote: >>>> > >>>> >> >>>> >> On 07.03.2014, at 11:55, roberto.minelli(a)usi.ch wrote: >>>> >> >>>> >>> Hi guys, >>>> >>> >>>> >>> I am experiencing a very strange problem that makes me think there is some shared memory problem with Pharo. >>>> >>> >>>> >>> Here are the steps that lead to the problem: >>>> >>> - I have an image, I do something (i.e., materializing objects with Fuel) >>>> >>> - I encounter a problem and a debugger pops up with a âself error: something" >>>> >>> - I close the debugger >>>> >>> - I close the image >>>> >> >>>> >> Do you save the image? If so, are you saving references to the already materialized objects? >>>> > >>>> > Of course, I did not save the image. Otherwise Iâd have understood the behavior. >>>> > >>>> >> >>>> >>> - I reopen the image >>>> >>> - I fix the bug (i.e., commenting the self error) >>>> >>> - I re-run the same thing as in the first step >>>> >>> - An OutOfMemory error appears. >>>> >>> >>>> >>> Any clue? >>>> >>> >>>> >>> Thanks, >>>> >>> Roberto

March 9, 2014

Re: [Pharo-dev] Windows FileSystem '\test\bar' not an absolute path

by btc＠openinworld.com

Ben Coman wrote: > > I have some strong concerns about the semantics of FileSystem on MS > Windows treating '\directory' as a relative path rather than an > absolute path. > > For example currently... > '/tmp/test.txt' asFileReference fullName --> > 'C:\Users\Ben\AppData\Roaming\Pharo\images\30790\tmp\test.txt' > > when it _should_ go... > '/tmp/test.txt' asFileReference fullName --> 'C:\tmp\x.txt' > > This seems to be by design per '\test\bar' below... > > WindowsStoreTest>>testAbsolutePath > #('c:\' 'C:\temp' 'A:\temp\test') do: [:each | > self assert: (WindowsStore current pathFromString: each) > isAbsolute ] > WindowsStoreTest>>testRelativePath > #('a' 'bin\foo' 'temp\test' '\test\bar') do: [:each | > self assert: (WindowsStore current pathFromString: each) > isRelative ] > > However taking as reference the Windows Command Shell (cmd.exe)... > (1) C:\> mkdir \a\b\a\c > (2) C:\> cd a > (3) C:\a> cd b > (4) C:\a\b> cd \a > (5) C:\a> > > observe that after 'cd \a' (4) the working directory becomes absolute > 'C:\a' rather than relative 'C:\a\b\a' . > > Microsoft defines [1] a file name is RELATIVE to the current directory > if it DOES NOT begin with: > * A single backslash, for example, "\directory" or "\file.txt". This > is also referred to as an ABSOLUTE path. > > Indeed all Windows applications I know operate this way. Using > different semantics is a bug. > > [1] > http://msdn.microsoft.com/en-us/library/aa365247.aspx#fully_qualified_vs._r… > > > What are your thoughts? > cheers -ben > > I propose something like the following changes... WindowsStoreTest>>testAbsolutePath #('c:\' 'C:\temp' 'A:\temp\test' '\test\bar') do: [:each | "<--MODIFIED" self assert: (WindowsStore current pathFromString: each) isAbsolute ] WindowsStoreTest>>testRelativePath #('a' 'bin\foo' 'temp\test' 'C:temp\test' ) do: [:each | "<--MODIFIED" self assert: (WindowsStore current pathFromString: each) isRelative ] Path>>absoluteWindowsPathRegex ^ (absoluteWindowsPathRegex ifNil: [ absoluteWindowsPathRegex := '([a-zA-Z]\:)?\\.*' asRegex ]) copy "<--MODIFIED" " absoluteWindowsPathRegex := '[a-zA-Z]\:\\.*' asRegex ]) copy" "<--PREVIOUS" Path>>first "<--ADDED" ^ self at: 1. WindowsStore>>printPath: aPath on: aStream (aPath first includes: $:) ifFalse: [ aStream nextPutAll: self currentDisk ; nextPut: self delimiter ]. "<--ADDED" aPath printOn: aStream delimiter: self delimiter WindowsStore>>currentDisk "<--ADDED" "Assumes workingDirectory is always an absolute path" ^ disk ifNil: [ disk = FileSystem workingDirectory path first ] after which... '/tmp/test.txt' asFileReference fullName --> 'C:\tmp\test.txt' This needs some polish. I haven't looked for adverse effects yet. However Pathtest, FileReferenceTest, FileSystemTest & WindowsStoreTest are all green. What do your think? cheers -ben

March 9, 2014

Windows FileSystem '\test\bar' not an absolute path

by Ben Coman

I have some strong concerns about the semantics of FileSystem on MS Windows treating '\directory' as a relative path rather than an absolute path. For example currently... '/tmp/test.txt' asFileReference fullName --> 'C:\Users\Ben\AppData\Roaming\Pharo\images\30790\tmp\test.txt' when it _should_ go... '/tmp/test.txt' asFileReference fullName --> 'C:\tmp\x.txt' This seems to be by design per '\test\bar' below... WindowsStoreTest>>testAbsolutePath #('c:\' 'C:\temp' 'A:\temp\test') do: [:each | self assert: (WindowsStore current pathFromString: each) isAbsolute ] WindowsStoreTest>>testRelativePath #('a' 'bin\foo' 'temp\test' '\test\bar') do: [:each | self assert: (WindowsStore current pathFromString: each) isRelative ] However taking as reference the Windows Command Shell (cmd.exe)... (1) C:\> mkdir \a\b\a\c (2) C:\> cd a (3) C:\a> cd b (4) C:\a\b> cd \a (5) C:\a> observe that after 'cd \a' (4) the working directory becomes absolute 'C:\a' rather than relative 'C:\a\b\a' . Microsoft defines [1] a file name is RELATIVE to the current directory if it DOES NOT begin with: * A single backslash, for example, "\directory" or "\file.txt". This is also referred to as an ABSOLUTE path. Indeed all Windows applications I know operate this way. Using different semantics is a bug. [1] http://msdn.microsoft.com/en-us/library/aa365247.aspx#fully_qualified_vs._r… What are your thoughts? cheers -ben

March 9, 2014

Re: [Pharo-dev] [Moose-dev] [Pharo-business] [ANN] DBPedia: Query Wikipedia from Pharo

by Pharo4Stef

Just avoiding to only manipulate strings would be already good. On 09 Mar 2014, at 11:22, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 03.03.2014 um 14:22 schrieb Johan Fabry <jfabry(a)dcc.uchile.cl>: > >> +1 to that! It would be good to have some kind of uniform syntax for constructing queries. Especially now that the use of JSON objects is quite common. >> > I would like to have that, too. I need to have query support for elasticsearch and I would do something similar like MongoQueries. The idea of having a common query syntax is nice but Iâm not convinced it will be easy to do. The parser needs to be easily extendable because most applications will have their custom additions to the base syntax. > > Norbert > >> The OP was actually referring to MongoQueries. To get some examples of the syntax see section 4 of https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… >> >> On Mar 3, 2014, at 10:13 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >>>> What would be nice is to have an abstraction like mongoTalk on top to avoid to manipulate strings but to manipulate query elements. >>> >>> That is a nice idea. >>> >>> Alexandre >> >> >> >> ---> Save our in-boxes! http://emailcharter.org <--- >> >> Johan Fabry - http://pleiad.cl/~jfabry >> PLEIAD lab - Computer Science Department (DCC) - University of Chile >> >> > >

March 9, 2014

Re: [Pharo-dev] base64.b64encode(data) equivalent

by Pharo4Stef

thanks sven Iâm reading Hbase connection and Iâm trying to understand it :) On 09 Mar 2014, at 09:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > ZnBase64Encoder new encode: 42 asByteArray. > => 'Kg==' > > (ZnBase64Encoder new decode: 'Kg==') asInteger. > => 42 > > There is also #asByteArrayOfSize: and signed/unsigned might come into play as well. > > Note that strictly speaking (as implemented by ZnBase64Encoder), Base64 is a binary to string encoding. But is it often used string to string (as in #base64Encoded and #base64Decoded, which are still implemented using Base64MimeConverter) but the explicit correct way is as in ZnUtils #encodeBase64: and #decodeBase64: using a character encoding. > > On 09 Mar 2014, at 09:09, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > >> around Zinc-Character-Encoding-Core >> :) >> >> Stef >> On 09 Mar 2014, at 09:07, Pharo4Stef <pharo4Stef(a)free.fr> wrote: >> >>> Iâm sure that we have that. I remember svenâs code using encoder >>> but I do not know where. >>> >>> # Method for encoding ints with base64 encoding >>> def encode(n): >>> data = struct.pack("i", n) >>> s = base64.b64encode(data) >>> return s >>> >> > >

March 9, 2014

Re: [Pharo-dev] Git & MS Windows path length restriction

by GOUBIER Thierry

Thanks Ben for that info about long file names in Windows, of importance when discussing file formats for smalltalk packages and git. Just that your link only describe how to get a significant diff display when dealing with zip files stored as-is inside a Git repository, not automagically zipping and unzipping in and out of git storage. Too bad :(. However, searching around that info points out that git will do a binary delta on a versionned zip file [1], which means storing zip files inside git is not that bad. [1] http://stackoverflow.com/questions/9973151/does-git-smartly-handle-a-zip-ar… Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de btc(a)openinworld.com [btc(a)openinworld.com] EnvoyÃ© : dimanche 9 mars 2014 16:43 Ã : metacello(a)googlegroups.com; Discusses Development of Pharo; Squeak Virtual Machine Development Discussion Objet : [Pharo-dev] Git & MS Windows path length restriction I started looking into Pharo Case 13030 "Many tests failing in MetacelloValidation Job on Jenkins" and even before getting into it, I've hit a stumbling block on Windows 7 with its pathName length restriction of 259 characters. I managed to isolate the problem as follows... MetacelloPlatform current downloadFile: 'https://github.com/dalehenrich/metacello-work/zipball/master' to: 'C:\tmp\github-dalehenrichmetacelloworkmaster.zip'. zip := ZipArchive new readFrom: 'C:\tmp\github-dalehenrichmetacelloworkmaster.zip'. zip extractAllTo: 'C:\tmp\unzippedByPharo' asFileReference. which produces the error "FileDoesNotExist: File @ C:\tmp\unzippedByPharo\dalehenrich-metacello-work-96e07b1\repository\Metacello-TestsMCB.package\MetacelloScriptingStandardTestHarness.class\instance\validateExpectedConfigurationClassName.expectedConfigurationVersion.expectedConfigurationRepository.expectedBaselineClassName.expectedBaselineVersion.expectedBaselineRepository..st" where the #size of that filename is 354 characters. Trying to drill into github-dalehenrichmetacelloworkmaster.zip from Windows Explorer produces error "The Compresses (zipped) file is invalid." However using 7Zip [1] I can extract the file so that _all_ files appear in the hierarchy, so it seems 259 is not a hard limit, and indeed that limit is imposed by the Windows Shell, since NTFS can have a path length of ~32K [2]. Operation of 7Zip was verified by: * From Pharo: zip members size --> 6007 * For cmd.exe: dir /b /s > dir.txt Open dir.txt into Notepad++ --> 6007 (after dir.txt line removed) Also Windows Explorer <Properties> reports (5277 files + 730 folders) = 6007 [1] www.7-zip.org [2] http://stackoverflow.com/questions/265769/maximum-filename-length-in-ntfs-w… Now presuming its reasonable for the working directory to have 30 characters, using... histogram := (zip members collect: [ :member | | mySize | mySize := member fileName size. (mySize >=230) ifTrue: [Transcript crShow: mySize printString , '-->' , member fileName printString ]. mySize. ]) asBag. produces... 306-->'dalehenrich-metacello-work-96e07b1/repository/Metacello-TestsMCB.package/MetacelloScriptingStandardTestHarness.class/instance/validateExpectedConfigurationClassName.expectedConfigurationVersion.expectedConfigurationRepository.expectedBaselineClassName.expectedBaselineVersion.expectedBaselineRepository..st' 252-->'dalehenrich-metacello-work-96e07b1/repository/Metacello-ToolBox.package/MetacelloToolBox.class/class/createBaseline.for.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups..st' 257-->'dalehenrich-metacello-work-96e07b1/repository/Metacello-ToolBox.package/MetacelloToolBox.class/class/modifyBaselineVersionIn.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups..st' 259-->'dalehenrich-metacello-work-96e07b1/repository/Metacello-ToolBox.package/MetacelloToolBox.class/class/modifyVersion.section.for.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups..st' 262-->'dalehenrich-metacello-work-96e07b1/repository/Metacello-ToolBox.package/MetacelloToolBox.class/instance/addSection.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups.versionSpecsDo..st' 265-->'dalehenrich-metacello-work-96e07b1/repository/Metacello-ToolBox.package/MetacelloToolBox.class/instance/modifySection.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups.versionSpecsDo..st' 278-->'dalehenrich-metacello-work-96e07b1/repository/Metacello-ToolBox.package/MetacelloToolBox.class/instance/modifySection.sectionIndex.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups.versionSpecsDo..st' So... * Are there many users of Smalltalk/git on Windows * What is the design plan for dealing with the long path name? I guess the change to using the unicode functions to get the 32K pathName length would need to happen in the VM. I wonder if instead of Smalltalk-git working with individual files in the file system, it might work directly from the a zip file. It seems git can be configured to accept zip files and unpack them before pushing into its repository [3]. Some benefits of this: * Avoid this problem on Windows * Accessing one stream when loading a from git repository might be faster than accessing many individual files * Git sees one file per method, but users see one file per package. * Git-zip-files might act more like familiar mcz files - that could be copied around the same - or even provide some convergence if an mcz held a file per method rather than a single source.st file. [3] http://tante.cc/2010/06/23/managing-zip-based-file-formats-in-git/ Interested in you thoughts. cheers -ben

March 9, 2014

Git & MS Windows path length restriction

by btc＠openinworld.com

I started looking into Pharo Case 13030 "Many tests failing in MetacelloValidation Job on Jenkins" and even before getting into it, I've hit a stumbling block on Windows 7 with its pathName length restriction of 259 characters. I managed to isolate the problem as follows... MetacelloPlatform current downloadFile: 'https://github.com/dalehenrich/metacello-work/zipball/master' to: 'C:\tmp\github-dalehenrichmetacelloworkmaster.zip'. zip := ZipArchive new readFrom: 'C:\tmp\github-dalehenrichmetacelloworkmaster.zip'. zip extractAllTo: 'C:\tmp\unzippedByPharo' asFileReference. which produces the error "FileDoesNotExist: File @ C:\tmp\unzippedByPharo\dalehenrich-metacello-work-96e07b1\repository\Metacello-TestsMCB.package\MetacelloScriptingStandardTestHarness.class\instance\validateExpectedConfigurationClassName.expectedConfigurationVersion.expectedConfigurationRepository.expectedBaselineClassName.expectedBaselineVersion.expectedBaselineRepository..st" where the #size of that filename is 354 characters. Trying to drill into github-dalehenrichmetacelloworkmaster.zip from Windows Explorer produces error "The Compresses (zipped) file is invalid." However using 7Zip [1] I can extract the file so that _all_ files appear in the hierarchy, so it seems 259 is not a hard limit, and indeed that limit is imposed by the Windows Shell, since NTFS can have a path length of ~32K [2]. Operation of 7Zip was verified by: * From Pharo: zip members size --> 6007 * For cmd.exe: dir /b /s > dir.txt Open dir.txt into Notepad++ --> 6007 (after dir.txt line removed) Also Windows Explorer <Properties> reports (5277 files + 730 folders) = 6007 [1] www.7-zip.org [2] http://stackoverflow.com/questions/265769/maximum-filename-length-in-ntfs-w… Now presuming its reasonable for the working directory to have 30 characters, using... histogram := (zip members collect: [ :member | | mySize | mySize := member fileName size. (mySize >=230) ifTrue: [Transcript crShow: mySize printString , '-->' , member fileName printString ]. mySize. ]) asBag. produces... 306-->'dalehenrich-metacello-work-96e07b1/repository/Metacello-TestsMCB.package/MetacelloScriptingStandardTestHarness.class/instance/validateExpectedConfigurationClassName.expectedConfigurationVersion.expectedConfigurationRepository.expectedBaselineClassName.expectedBaselineVersion.expectedBaselineRepository..st' 252-->'dalehenrich-metacello-work-96e07b1/repository/Metacello-ToolBox.package/MetacelloToolBox.class/class/createBaseline.for.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups..st' 257-->'dalehenrich-metacello-work-96e07b1/repository/Metacello-ToolBox.package/MetacelloToolBox.class/class/modifyBaselineVersionIn.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups..st' 259-->'dalehenrich-metacello-work-96e07b1/repository/Metacello-ToolBox.package/MetacelloToolBox.class/class/modifyVersion.section.for.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups..st' 262-->'dalehenrich-metacello-work-96e07b1/repository/Metacello-ToolBox.package/MetacelloToolBox.class/instance/addSection.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups.versionSpecsDo..st' 265-->'dalehenrich-metacello-work-96e07b1/repository/Metacello-ToolBox.package/MetacelloToolBox.class/instance/modifySection.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups.versionSpecsDo..st' 278-->'dalehenrich-metacello-work-96e07b1/repository/Metacello-ToolBox.package/MetacelloToolBox.class/instance/modifySection.sectionIndex.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups.versionSpecsDo..st' So... * Are there many users of Smalltalk/git on Windows * What is the design plan for dealing with the long path name? I guess the change to using the unicode functions to get the 32K pathName length would need to happen in the VM. I wonder if instead of Smalltalk-git working with individual files in the file system, it might work directly from the a zip file. It seems git can be configured to accept zip files and unpack them before pushing into its repository [3]. Some benefits of this: * Avoid this problem on Windows * Accessing one stream when loading a from git repository might be faster than accessing many individual files * Git sees one file per method, but users see one file per package. * Git-zip-files might act more like familiar mcz files - that could be copied around the same - or even provide some convergence if an mcz held a file per method rather than a single source.st file. [3] http://tante.cc/2010/06/23/managing-zip-based-file-formats-in-git/ Interested in you thoughts. cheers -ben

March 9, 2014