- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 1ce6ea: 40305

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 1ce6eaf214fbe614c9ded6f72a2697afb938711d https://github.com/pharo-project/pharo-core/commit/1ce6eaf214fbe614c9ded6f7… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-15 (Wed, 15 Oct 2014) Changed paths: A Kernel.package/SymbolicBytecode.class/instance/mapping/sourceInterval.st A Kernel.package/SymbolicBytecode.class/instance/mapping/sourceNode.st M Manifest-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/setTextModelForClassOrMethod_.st M NECompletion.package/NOCCompletionTable.class/class/class initialization/initialize.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script305.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40305.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40305 13535 Class code wrongly styled in critic browser https://pharo.fogbugz.com/f/cases/13535 14236 add #sourceInterval and #sourceNode to SymbolicBytecode https://pharo.fogbugz.com/f/cases/14236 14238 Replace Announcer>>#on:send:to:s senders in NECompletion https://pharo.fogbugz.com/f/cases/14238 http://files.pharo.org/image/40/40305.zip

Oct. 15, 2014

Re: [Pharo-dev] [squeak-dev] Re: [Pharo-users] Trouble opening large files

by stepharo

Do we create an issue for the Pharo-vm? Stef On 14/10/14 21:29, Nicolai Hess wrote: > Ah, good to know. At least for squeak, > bug 7522 can be closed :) > > Nicolai > > 2014-10-14 20:49 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com > <mailto:eliot.miranda@gmail.com>>: > > Hi Nicolai, > > On Tue, Oct 14, 2014 at 11:26 AM, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > > There is a bug report on mantis for squeaks unix vm. > I think this applies to pharo too, although I don't know if this > bug is still valid on recent squeak vm. > > http://bugs.squeak.org/view.php?id=7522 > > > yes, one must compile with -D_FILE_OFFSET_BITS=64. The Cog VMs > are also built with -D_GNU_SOURCE. > > Here's a line from a Squeak file list on the current Cog VM: > > (2014.10.11 07:00:46 7,115,143,880) > Formula1.2014.Round16.Russia.Qualifying.BBCOneHD.1080i.H264.English-wserhkzt.ts > > > No 32-bit limit here. > > > > 2014-10-14 17:43 GMT+02:00 Evan Donahue <emdonahu(a)gmail.com > <mailto:emdonahu@gmail.com>>: > > The OS is Arch Linux. > > I can read the file with less. > > The problem, insofar as I can trace it, seems to stem from > this line in UnixStore: > > Primitives lookupDirectory: encodedPath filename: > encodedBasename > > When I have my 57G file there this line returns nil. If I > move the 57G file and create a small file with the same > name, the same command successfully finds the file. I am > not sure how large a file must be to cause this issue, but > A 1.5G file works fine. > > On Tue, Oct 14, 2014 at 8:17 AM, Nicolai Hess > <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: > > 2014-10-14 6:38 GMT+02:00 Evan Donahue > <emdonahu(a)gmail.com <mailto:emdonahu@gmail.com>>: > > Hi, thanks for the reply. > > The response is the same: "MessageNotUnderstood: > False>>humanReadableSIByteSize." > > This happens both to print-it as well as to > do-it-and-go. Running the command on the > neighboring "wiki.torrent" torrent file yields the > correct 54kb. > > Thanks, > Evan > > On Tue, Oct 14, 2014 at 12:24 AM, Tudor Girba > <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>> wrote: > > Hi, > > If I understand correctly, the failure occurs > while navigating in the "Items" presentation. > > I cannot reproduce this problem because I do > not have enough disk space for such a large > file :). But, could you do the following and > let me know what the outcome is: > > 'path/to/your/large/file.xml' > asFileReference humanReadableSize > > ? > > Cheers, > Doru > > > > On Tue, Oct 14, 2014 at 2:27 AM, Evan Donahue > <emdonahu(a)gmail.com > <mailto:emdonahu@gmail.com>> wrote: > > Hello, I've run into some odd behavior and > wanted to check whether I might be missing > something: > > I have downloaded a copy of the english > wikipedia as an xml file and am hoping to > (sax) parse it. However, I can't even seem > to get pharo to recognize that the file > exists. > > If I open FileSystem disk root in the > playground and naigate, attempting to > enter the folder containing the (57G) xml > file fails with "MessageNotUnderstood: > False>>humanReadableSIByteSize." Likewise > if I get a FileReference with FileSystem > disk root / 'path' / 'to' / 'file' then > self exists returns false and the parser > fails. > > Am I doing something wrong? Should I be > able to do this? > > The version number is #40283 > > Thanks, > Evan > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" > > > > > Which OS ? > Can you check with other programs if this file is > readable at all? > > > > > Nicolai > > > > > > > > > > > -- > best, > Eliot > >

Oct. 15, 2014

Re: [Pharo-dev] creating custom browsers out of GTInspector extensions

by Marcus Denker

> On 14 Oct 2014, at 23:26, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Now, that more people are playing with the GTInspector, I would like to raise another point that might otherwise go unnoticed: The inspector extensions do not only work in the inspector, but can also be combined in other browsers as well. > We could replace (most of) the FileBrowser by GLMPager new with: [ :pager | pager show: [ :composite :file | composite title: file basename. file gtInspectorItemsIn: composite. file gtInspectorContentsIn: composite ]; title: 'FileBrowser' ]; openOn: FileSystem disk workingDirectory Where it replaces FileList linesOfCode ==> 1075 (plus three more helper classes). Of course this does a little bit more, but most of that is at the wrong spot anyway. (editor for text files, API for file selection on the class side). Marcus

Oct. 15, 2014

Re: [Pharo-dev] BlockClosure source code

by Marcus Denker

> On 14 Oct 2014, at 22:01, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > I love these little things. > > This is a great example of how value should not be confused with cost. Small can be quite big after all :) It should be noted that there is almost no code âwastedâ on thisâ¦ the parser that creates the objects behind replaces InstructionPrinter (as we can just printOn: the SymbolicBytecodes for the longPrintString). The GTInspector related code is 5 short methods, in the end, after building the tool the system was smaller. Marcus

Oct. 15, 2014

Re: [Pharo-dev] Tests around Pharo

by mschepens

Well thank you again for your advices. We'll do operations for slices around 11-12 o'clock. For tests that Hilaire proposed (Dr Geo), we met some pharo committers during events in our university, and they suggested us to work mainly around collections, so we decided to focus to Collections part during the development time we had. About the license agreements I didn't see it anywhere, I will print it and send it to Damien this evening. Once our code will be accepted, we'll close the loop by reviewing the image integrating it. -- View this message in context: http://forum.world.st/Tests-around-Pharo-tp4777295p4784629.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 15, 2014

Re: [Pharo-dev] [squeak-dev] Re: [Pharo-users] Trouble opening large files

by David T. Lewis

On Tue, Oct 14, 2014 at 09:29:51PM +0200, Nicolai Hess wrote: > Ah, good to know. At least for squeak, > bug 7522 can be closed :) > Closed. I'll note also that LFS is needed for saving large 64-bit image files :-) Dave

Oct. 14, 2014

creating custom browsers out of GTInspector extensions

by Tudor Girba

Hi, Now, that more people are playing with the GTInspector, I would like to raise another point that might otherwise go unnoticed: The inspector extensions do not only work in the inspector, but can also be combined in other browsers as well. For example, the attached picture shows a Pillar browser that shows only the presentations relevant to editing Pillar books. And the code looks like: GLMPager new with: [ :pager | pager show: [ :composite :file | composite title: file basename. file gtInspectorItemsIn: composite. file gtInspectorPillarConfigurationIn: composite. file gtInspectorPillarIn: composite. file gtInspectorPillarProjectIn: composite. file gtInspectorPngIn: composite. file gtInspectorGifIn: composite. file gtInspectorContentsIn: composite ] ]; openOn: FileSystem disk workingDirectory [image: Inline image 1] See here some more details: http://www.humane-assessment.com/blog/creating-custom-browsers-out-of-inspe… The interesting thing is that we can now easily imagine creating rather sophisticated tools with little code and that we only use for a very short time (like minutes). This has a rather high disruption potential given that no other environment I know of allows for something like this. Let us know what you think. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Oct. 14, 2014

Re: [Pharo-dev] BlockClosure source code

by Tudor Girba

I love these little things. This is a great example of how value should not be confused with cost. Small can be quite big after all :) Doru On Tue, Oct 14, 2014 at 4:46 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Very nice !! > > On 14 Oct 2014, at 16:42, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> > >> On 10 Oct 2014, at 12:29, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> > >> > >>> On 10 Oct 2014, at 10:57, Jan KurÅ¡ <kurs(a)iam.unibe.ch> wrote: > >>> > >>> Hi All, > >>> > >>> Thank you for the replies. I see it is not an easy bug to fix. Do you > have any idea, when this can be fixed? > >>> > >> I will try to fix it next week... > >> > >>> Or can you suggest me some other way/workaround, how to get/generate > the source code of a block? > >>> > >> > >> The old compiler used a hack to decompile blocks for getting a textual > representationâ¦ one could port > >> the code from Pharo2 to the Package OpalDecompiler in Pharo4. (but I > actually like the current scheme of > >> using the byte code-offset-to-AST mapping more). > >> > > > > step one: A nice toolâ¦ GTInspector view of the byte codes that > highlights what is thinks is the corresponding code in the source. > > (This living Bytecode view replaces what before just printed out the > #longPrintString of the CompiledMethod): > > > > > > > > <Playground.jpeg> > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 14, 2014

Re: [Pharo-dev] Mysteries of the compiler

by Nicolai Hess

2014-10-14 20:31 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Tue, Oct 14, 2014 at 11:15 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Thank you eliot, marcus >> >> Yes I know your blog it is a great source of information. >> I am curious how the squeak compiler/debugger handles this (I'll look >> into it). >> > > There's no scope at run-time, only at compile time. AT compile time the > BlockNodes for optimized blocks get checked for the optimized selectors > (ifTrue: whileTrue and: et al) and have a flag set if they can be optimized > (have the right number of arguments). At run-time there's no evidence of > an optimized block. One is left in the enclosing method/block activation. > > About opal and optimized block scope: >> Yes, I like the way this "special" non-scope is modelled with >> its own scope class. >> But somehow the whileTrue: receiver block is handled different than >> the ifTrue: block argument. >> > > How so? Is it the source extent that is wrong? > 1. sometimes the debugger can not inspect a single tempvar (list of all temps is working) 2. number of temp vars (in method header) is wrong: | a b c | a := 1. b := 2. c := 3. [[a asString] on: Error do: [:ex | a value: a value: b value: c]. c < 0] whileTrue. method header numtemps 1 | a b c | a := 1. b := 2. c := 3. c < 0 ifTrue: [ [ a asString ] on: Error do: [ :ex | a value: a value: b value: c ]. c < 0 ]. ^ a method header numtemps 3 both methods define a block with a nested block. In the first method it is the receiver of #whileTrue: the second method it is the argument to #ifTrue: I think both blocks are optimized, but somehow the block receiving the whileTrue: message makes the computation for the number of tempvars wrong. > > 2014-10-14 17:41 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> Hi Marcus, >>> >>> On Tue, Oct 14, 2014 at 4:09 AM, Marcus Denker <marcus.denker(a)inria.fr> >>> wrote: >>> >>>> >>>> > On 12 Oct 2014, at 11:49, Nicolai Hess <nicolaihess(a)web.de> wrote: >>>> > >>>> > I tried to solve issues >>>> > "13260 inspecting variables in the debugger fails in some cases" and >>>> > "14058 Inconsistent information in debugger" >>>> > and found some oddities in the way opal (compiler and the debuggermap) >>>> > handles tempory variables. >>>> > I am not sure if these are bugs. >>>> > >>>> > 1. order of temporaries: >>>> > Evaluating this method >>>> > |a b c| >>>> > a:=1. >>>> > b:=2. >>>> > c:=3. >>>> > thisContext tempNames logCr. >>>> > ["in a block ! " thisContext tempNames logCr . a+b+c ] value. >>>> > >>>> > prints in the transcript >>>> > #(#a #b #c) >>>> > #(#a #b #c) >>>> > >>>> > - ok, both contexts, the method and block context, use the same >>>> > ordering for the tempories >>>> > >>>> > writing on one variable in the block context require an indirection >>>> vector for >>>> > the variable >>>> > >>>> > |a b c| >>>> > a:=1. >>>> > b:=2. >>>> > c:=3. >>>> > thisContext tempNames logCr. >>>> > [b:=1. thisContext tempNames logCr. a+b+c ] value. >>>> > >>>> > here the variable b is written within the block context. This method >>>> prints >>>> > #(#b #a #c) >>>> > #(#a #c #b) >>>> > >>>> > - strange the variable order has changed and is not the same in both >>>> contexts. >>>> > >>>> >>>> Yes, but behind the scenes a lot is going onâ¦ when you assign a >>>> variable in a block, this >>>> variable can not be allocated like a normal temp. There is instead an >>>> array (temp vector) allocated where this >>>> variable lives. Then *this array* has a âtempâ and is accessed in the >>>> block like the variables >>>> in the case of no assignment. >>>> >>> >>> Niolai, you're probably aware of it but there's an extensive write up of >>> the design on my blog: >>> >>> http://www.mirandabanda.org/cogblog/2008/06/07/closures-part-i/ >>> >>> http://www.mirandabanda.org/cogblog/2008/07/22/closures-part-ii-the-bytecod… >>> >>> http://www.mirandabanda.org/cogblog/2008/07/24/closures-part-iii-the-compil… (especially >>> section "The Closure Analysis") >>> >>> This means that there can not be an order: some variables live in >>>> arrays, others in the context. >>>> The only thing that you have is a scope that nows how a name maps to a >>>> specific offset or two >>>> (offset of temp of the âtemp vector + offset inside this temp vector). >>>> >>> >>> I disagree slightly. The Squeak compiler maintains order, both in temps >>> and in indirect temps. But whether a temp is direct or indirect depends on >>> a simple analysis of a single method. I still think it is part of the >>> Smalltalk culture to KISS and e.g. maintain the order of temps. >>> >>> One could beautify it a bit by sorting the names according to the >>>> original definition order, though. >>>> (we should look onto that). >>>> >>> >>> The current exception system needs to access temps, e.g. ensure:'s and >>> ifCurtailed:'s complete and on:do:'s handlerActive. Isn't it really >>> important to maintain ordering? It certainly makes introspection easier. >>> One can go through a name-based interface but that is likely to be much >>> much slower in what is a perfrmance-critical part of the system. >>> >>> >>>> >>>> But even if we do, this does not mean that b has offset 2 in the >>>> example, as it lives in an array... >>>> >>> >>> Right. >>> >>> >>>> >>>> >>>> > 2. OCOptimizedBlockScope >>>> > >>>> > Consider a whileTrue: call >>>> > ["A-Block"] whileTrue:["B-Block"] >>>> > or an ifTrue: >>>> > ("some boolean value") ifTrue:["C-Block"] >>>> > stepping into the blocks with the debugger and reading the >>>> > values for a tempoariy variable shows that every block has >>>> > an OCOpotimizedBlockScope as its scope. >>>> > Are all 3 blocks the same kind of "optimized blocks"? because -> >>>> > >>>> Yes, we tried two ideas >>>> The first move only real existing scopes, that means, instead of an >>>> optimised scope >>>> point to the scope that all these optimized blocks are flattened into. >>>> But that was not nice and we could not get it to work. >>>> Instead, we opted into modelling the concept of the optimised scope: >>>> on the AST >>>> level, the block has a scope (like all blocks), but when you add an >>>> entry (or query), >>>> it will forward to the ârealâ existing scope. >>>> >>>> I still like it, it makes things very explicit. >>>> >>>> > 3. Blocks within optimized blocks >>>> > This method prints the number of tempories on the Transcript >>>> > (the on:do: call is just a dummy for an "block within a block" >>>> > but the important part is the usage of the three variables >>>> > in the do-block) >>>> > >>>> > |a b c| >>>> > a:=1. >>>> > b:=2. >>>> > c:=3. >>>> > (c>0) ifTrue:[ >>>> > [ a asString ] on:Error do:[:ex | a value:a value:b value:c]. >>>> > ]. >>>> > thisContext method numTemps logCr. >>>> > a >>>> > >>>> > The output on the transcript is "3" >>>> > - ok >>>> > >>>> > This method is like the one above, but the nested block >>>> > is in the receiver of the whileTrue:[] call (again, an optimized >>>> block, right?) >>>> > >>>> > |a b c| >>>> > a:=1. >>>> > b:=2. >>>> > c:=3. >>>> > >>>> > [ >>>> > [ a asString ] on:Error do:[:ex | a value:a value:b value:c]. >>>> > c <0 ] whileTrue:[]. >>>> > thisContext method numTemps logCr. >>>> > a >>>> > >>>> > The output on the Transcript is "1" >>>> > And it depends on the number of used variables in the do-Block >>>> > The same method but with the do-Block >>>> > do:[:ex | a value:a value:b] >>>> > would print 2 as number of temporaries. >>>> > >>>> >>>> >>>> Hmmâ¦ I need to think about this one. It looks strange, yes. >>>> >>>> Marcus >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> best, >>> Eliot >>> >> >> > > > -- > best, > Eliot >

Oct. 14, 2014

Re: [Pharo-dev] OSProcess in 3.0

by Thierry Goubier

Le 14/10/2014 14:15, David T. Lewis a Ã©crit : > On Tue, Oct 14, 2014 at 07:19:10AM +0200, Thierry Goubier wrote: >> Hi Dave, >> >> took me a while to do some testing. It seems there is an issue, but I >> couldn't find out where. First, the data: >> >> Loading a package from a local gitfiletree repository (get from the >> command a zipped git archive containing the package) : >> >> 4.5.11, 4.6.8: 2132 msec. >> 4.5.12, 4.6.9: 50847 msec. >> >> I tried to rewrite the main command, remove the closePipes, etc... No >> change in the runtime, so your right. >> >> Profiling doesn't help much: execution time is mostly idle time (but >> with a significant increase on PipeableOSProcess commands: goes from >> invisible to 2700 ms. A user break in the middle shows it delay waiting >> on output of the external process). >> >> Only hint I could see is that it seems to be linked with the size of the >> output of the command. > > Thierry, > > Aha! I am quite sure that you have located the problem. There must be > something preventing the OS process from running to completion with > a larger amount of output data. It definitely sounds like a bug in my > latest update to Pipeable OSProcess. The strange thing is that it runs to completion (i.e. I got no errors; if any data was missing or corrupted on output, my load would fail); but a lot slower than it should be. > Thank you very much for finding this. I will get it fixed as quickly > as I can. Thanks. I'm unable to help you much, I'm afraid :( Thierry

Oct. 14, 2014