- Pharo-dev - lists.pharo.org

issue with large file path on windows
by Nicolai Hess Oct. 13, 2015

Oct. 13, 2015

For those who had problems with pharo on windows and github based repositories, I built a windows vm with support for long paths: https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=shari… For browsing directories with large paths (FileList or Inspect), you may need one additional change in the image (But I am not really sure about that) : DiskStore>>initialize super initialize. maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 ]. please test and give feedback. This wasn't as easy as I thought, and I had to make some more changes for the file permissions (the stat-functions don't work for files with long paths). Please test other file/folder operations. nicolai

8 21

really
by Robert Withers Oct. 13, 2015

Oct. 13, 2015

This is what I want to build. What do you suggest I do? Thanks, Robert

2 2

[ANN] New SqueakSSL binaries (v0.2.0b) for Linux
by Tobias Pape Oct. 12, 2015

Oct. 12, 2015

Hi all, I've created a new version of the SqueakSSL binaries: https://github.com/itsmeront/squeakssl/releases/tag/v0.2.0b Only changes: â¢ Linked the Linux binary statically against LibreSSL 2.2.3 (was 2.2.1) â¢ Produce SqueakSSL and so.SqueakSSL with the correct sonames â¢ Explicitly link the Linux binaries with librt (was omitted by default) The OSX and Windows versions stayed. The actual C code did not change. Best regards -Tobias

1 0

Re: [Pharo-dev] Problems with a large block
by Nicolai Hess Oct. 12, 2015

Oct. 12, 2015

2015-10-08 23:45 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Nicolai, > > On Thu, Oct 8, 2015 at 2:27 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Hello Eliot, and thanks for your time. >> >> >> In our (pharo) implementation for sourceNodeForPC, we start at the >> AST-Node of >> the compiled method, get the IR (IntermediateRepresentation) and scan >> this sequence of IRNodes >> until we finally find that one, that maps to the bytecode of the closure >> creation code (this should be a IRPushClosureCopy). >> The problem is now, we don't find (always) the right IRNode, and it >> depens on the number of local temps, if this is > 3 we don't hit the right >> one. >> > > That's very strange. Can you construct a synthetic example of two simple > blocks, one with three temps and and one with four temps and show me the > difference in the byte code? > [ :x | | a b c | a:=b:=c:=x ] "calling #sourceNode gives a RBBlockNode - ok" Bytecode 13 <8F 01 00 0B> closureNumCopied: 0 numArgs: 1 bytes 17 to 27 17 <73> pushConstant: nil 18 <73> pushConstant: nil 19 <73> pushConstant: nil 20 <10> pushTemp: 0 21 <81 43> storeIntoTemp: 3 23 <81 42> storeIntoTemp: 2 25 <81 41> storeIntoTemp: 1 27 <7D> blockReturn 28 <7C> returnTop [ :x | | a b c d | a:=b:=c:=d:=x ] "calling #sourceNode gives a RBMethodNode - not ok" Bytecode 13 <8F 01 00 0E> closureNumCopied: 0 numArgs: 1 bytes 17 to 30 17 <73> pushConstant: nil 18 <73> pushConstant: nil 19 <73> pushConstant: nil 20 <73> pushConstant: nil 21 <10> pushTemp: 0 22 <81 44> storeIntoTemp: 4 24 <81 43> storeIntoTemp: 3 26 <81 42> storeIntoTemp: 2 28 <81 41> storeIntoTemp: 1 30 <7D> blockReturn 31 <7C> returnTop As I wrote above, in Pharo, to get the sourceNode we try to find the push closure bytecode from "startpc - 1" by traversing the IR and try to get the IRNode with matching "bytecodeOffset". The bytecodeOffsets for the above blocks: [ :x | | a b c | a:=b:=c:=x ] "bytecodeOffset -> IR" 19->pushClosureCopyCopiedValues: #() args: #(#x) 28->returnTop 20->pushTemp: #x 22->storeTemp: #c 24->storeTemp: #b 26->storeTemp: #a 27->blockReturnTop [ :x | | a b c d | a:=b:=c:=d:=x ] "bytecodeOffset -> IR" 20->pushClosureCopyCopiedValues: #() args: #(#x) 31->returnTop 21->pushTemp: #x 23->storeTemp: #d 25->storeTemp: #c 27->storeTemp: #b 29->storeTemp: #a 30->blockReturnTop Both blocks don't have a bytecodeOffset matching the bytecode of the pushclosure (13), but we start the search from "startpc - 1" (= 16) and do a loop from 0 to -3 (because bytecodes can have a length of 1,2 or 4) For the first block, this works bytecodeOffset 19 = 16 - (-3) For the second block this does not work, somehow the bytecodeoffset value depends on the number of local temps. And for the second block this is one greater. > And my interpretation was, the IRPushClosureCopy node has the wrong >> "bytecode offset" (whatever this is). The bytecodeOffset value (somehow) >> depends on the number of local temps, but maybe this is right (for >> whatever this is used) and we are just using it wrong for in this situation. >> > > So you need to ask Marcus how to interpret bytecodeOffset. The thing is, > it should be simple. One has: > > BlockCreationBytecode > any number of pushConstant: nil's (0 to N) > first byte code in block > last bytecode in block (always a blockReturnTop) > > and a block's startup is always that of the byte immediately following the > BlockCreationBytecode. So if the byte code offset is somehow the span of > the "any number of pushConstant: nil's (0 to N)" then there's a bug in the > IR somewhere when the number of temps is > 3. But if that's not what it > means then, well, I don't know what the problem is. > >

3 3

Relation between Garage PG and PGv2
by Esteban A. Maringolo Oct. 12, 2015

Oct. 12, 2015

Hi all, and Guille Polito in particular, I'm loading the Garage classes into Pharo 4, and I see the Garage-Postgres package "duplicates" the classes of the PostgresV2 package, but instead of using the PG prefix, it uses the GA prefix. This is in particular with the case of Garage-Postgres-Protocol package. Why is it so? Because even GAConnection>>#buildDefaultConnectionArgs (which is a replica of PGConnection) references PGConnectionArgs instead of GAConnectionArgs, which is the replica of the first. QUESTION: Isn't Garage a "common API" for the *existing* drivers? (like a common wrapper), and if so it delegates the protocol handling to the real driver? In the PostgresV2 package in this case, to PG prefixed classes. Regards! Esteban A. Maringolo

2 2

[ANN] Pharo Sprint October 23
by marcus.denker＠inria.fr Oct. 12, 2015

Oct. 12, 2015

We will organize a Pharo sprint / Moose dojo Friday, 23th October, starting at 10:00am. (Local Time Lille). It will be at the Inria Lille, Building B, third floor (RMoD offices). Remotely, you can join us on the official IRC channel #pharo on irc.freenode.net <http://irc.freenode.net/> server. During the sprint, we will try to synchronize local and remote Pharo sprinters. As the building is not open to the public, please contact us before if you plan to come.

1 0

hello
by SebastiÃ¡n Krynski Oct. 12, 2015

Oct. 12, 2015

Hello my name is SebastiÃ¡n Krynski from Buenos Aires, Argentina. Just writing to let you know that I'm starting to work on adding an atomic swap operator in Pharo , guaranteed not to be interrupted by the VM. The operator will be used this way: a :=: b meaning 'swap variable a with variable b'. In order to do this I will be modifying the VM and the Compiler . I'm working under the direction of INRIA and Gabriela ArÃ©valo.

5 7

Another pass on catalog web-site (Styling)
by Esteban Lorenzano Oct. 12, 2015

Oct. 12, 2015

Hi, I made another pass on catalog web-site. This time I just enhanced a bit the stylingâ¦ still a lot to do but is looking better and better: http://catalog.pharo.org (you might need a force refresh) But in fact, this announce is just an excuse to remember you to enhance your configurations with catalog information as described here: http://catalog.pharo.org/catalog/note-for-developers Also, if your configuration is proved to work on Pharo 3, 4 or 5, please copy your configuration into that repository, to avoid it to appear under âUnstableâ tag. The Catalog is just as good as the information it provides: there is A LOT of very good packages no one will ever notice (like Aconcagua, for example), that does not provide *any* information and therefore they will never be used :( PLEASE PLEASE PLEASE UPDATE YOUR CONFIGURATIONS! cheers, Esteban

2 1

[pharo-project/pharo-core]
by GitHub Oct. 12, 2015

Oct. 12, 2015

Branch: refs/tags/50382 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] 9ef1c3: 50382
by GitHub Oct. 12, 2015

Oct. 12, 2015

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 9ef1c30b540a7418d150dede106373b6f4ef3111 https://github.com/pharo-project/pharo-core/commit/9ef1c30b540a7418d150dede… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-12 (Mon, 12 Oct 2015) Changed paths: M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/stable_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version20_.st A Deprecated50.package/MultistateLabelMorph.class/README.md A Deprecated50.package/MultistateLabelMorph.class/definition.st A Deprecated50.package/MultistateLabelMorph.class/instance/accessing/colorMap.st A Deprecated50.package/MultistateLabelMorph.class/instance/accessing/colorMap_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/defaultColorMap.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/disabledColor.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/disabledColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/drawOn_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/initWithContents_font_emphasis_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/interactionState_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/mouseOverColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/normalColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/pressedColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedDisabledColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedMouseOverColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedPressedColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/initialization/initialize.st M Komitter.package/Komitter.class/instance/announcement/mcPackageModified_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/README.md R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/definition.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/accessing/colorMap.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/accessing/colorMap_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/defaultColorMap.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/disabledColor.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/disabledColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/drawOn_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/initWithContents_font_emphasis_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/interactionState_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/mouseOverColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/normalColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/pressedColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedDisabledColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedMouseOverColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedPressedColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/initialization/initialize.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50381.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50382.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50381.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50382.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50382 16730 Should sync back Rubric https://pharo.fogbugz.com/f/cases/16730 16765 Typo https://pharo.fogbugz.com/f/cases/16765 16766 Deprecate unreferenced/unused MultistateLabelMorph https://pharo.fogbugz.com/f/cases/16766 http://files.pharo.org/image/50/50382.zip

1 0