January 2016 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Jan. 26, 2016

[pharo-project/pharo-core] 16c0bd: 50548

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 16c0bdd2c243c69f7f77f1315439867d4f656209 https://github.com/pharo-project/pharo-core/commit/16c0bdd2c243c69f7f77f131… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-26 (Tue, 26 Jan 2016) Changed paths: R Athens-Cairo.package/AthensCairoCanvas.class/class/converting/asNBExternalType_.st R Athens-Cairo.package/AthensCairoSurface.class/class/converting/asNBExternalType_.st M Athens-Cairo.package/AthensCairoSurface.class/class/instance creation/createFromFile_ifFailed_.st R Athens-Cairo.package/AthensCairoSurface.class/class/removeMe/createGetSurfaceFormatFnOld.st R Athens-Cairo.package/AthensCairoSurface.class/class/removeMe/createLockSurfaceFnOld.st R Athens-Cairo.package/AthensCairoSurface.class/class/removeMe/createShowSurfaceFnOld.st R Athens-Cairo.package/AthensCairoSurface.class/class/removeMe/createUnlockSurfaceFnOld.st R Athens-Cairo.package/AthensCairoSurface.class/class/removeMe/fnPtr_.st R Athens-Cairo.package/AthensCairoSurface.class/class/removeMe/testGetSurfaceFormat_width_height_depth_isMSB_.st R Athens-Cairo.package/AthensCairoSurface.class/class/removeMe/testLockSurface_pitch_x_y_w_h_.st R Athens-Cairo.package/AthensCairoSurface.class/class/removeMe/testSurfacePluginCallbacks.st M Athens-Cairo.package/CairoFontFace.class/instance/initialize-release/initialize.st M Athens-Cairo.package/CairoFontFace.class/instance/initialize-release/initializeWithFreetypeFace_.st M Athens-Cairo.package/CairoFontOptions.class/instance/initialize-release/initialize.st M Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/accessing - font metrics/glyphsOf_from_to_.st M Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/private/convertString_len_ofFont_toGlyphs_numGlyphs_x_y_.st R Athens-Cairo.package/CairoLibraryLoader.class/README.md R Athens-Cairo.package/CairoLibraryLoader.class/class/linux/cantFindCairoOnLinux.st R Athens-Cairo.package/CairoLibraryLoader.class/class/linux/pathToCairoOnLinux.st R Athens-Cairo.package/CairoLibraryLoader.class/class/private/getLibraryPath.st R Athens-Cairo.package/CairoLibraryLoader.class/class/private/loadCairoLibrary.st R Athens-Cairo.package/CairoLibraryLoader.class/class/public/getLibraryHandle.st R Athens-Cairo.package/CairoLibraryLoader.class/definition.st M Athens-Cairo.package/CairoScaledFont.class/instance/initialize-release/initWithFace_.st M Athens-Cairo.package/CairoScaledFont.class/instance/initialize-release/initialize.st R Athens-Cairo.package/CairoUTF8Converter.class/instance/not finished yet/convertByteString_.st R Athens-Cairo.package/CairoUTF8Converter.class/instance/not finished yet/convertUnicode_.st R Athens-Cairo.package/CairoUTF8Converter.class/instance/not finished yet/convertUnicode_conversionLabels_.st R Athens-Cairo.package/CairoUTF8Converter.class/instance/not finished yet/convertWideString_.st R Athens-Cairo.package/CairoUTF8Converter.class/instance/not finished yet/store_accumulated_.st M Morphic-Core.package/Morph.class/instance/macpal/flash.st A Morphic-Core.package/Morph.class/instance/macpal/flashDone_.st A Morphic-Core.package/Morph.class/instance/macpal/flashFillStyle.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50547.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50548.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50547.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50548.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Shout.package/SHRBTextStyler.class/instance/private/style_ast_.st Log Message: ----------- 50548 17474 adapt Athens to UnifiedFFI 0.11 (pointer arity logic) https://pharo.fogbugz.com/f/cases/17474 17421 RubTextMethodLink and RubTextClassLink Leaks (TextStyling related) https://pharo.fogbugz.com/f/cases/17421 17442 Improve Morph>>#flash https://pharo.fogbugz.com/f/cases/17442 http://files.pharo.org/image/50/50548.zip

Jan. 26, 2016

Re: [Pharo-dev] Launcher Mac CI -> Broken Executable

by Sean P. DeNigris

Sean P. DeNigris wrote > > Sean P. DeNigris wrote >> "Pharo" is damaged and can't be opened. You should move it to the Trash. > I downloaded 0.2.9 [1] and got the same error message :/ Okay, google revealed more Apple evil empire nonsense. Starting in Mountain Lion, when you try to launch an app for the first time that is from an unknown developer, instead of telling you that, they give you this totally misleading message. The fix is to temporarily allow apps from all sources in the System Preferences [1]. Once Launcher has been launched once, you can change it back. [1] https://www.yourkit.com/download/mountain_lion.html ----- Cheers, Sean -- View this message in context: http://forum.world.st/Launcher-Mac-CI-Broken-Executable-tp4820123p4874235.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 26, 2016

Re: [Pharo-dev] Launcher Mac CI -> Broken Executable

by Sean P. DeNigris

Sean P. DeNigris wrote > "Pharo" is damaged and can't be opened. You should move it to the Trash. Back out of business :/ I downloaded 0.2.9 [1] and got the same error message :/ [1] https://ci.inria.fr/pharo/view/all/job/Launcher/PHARO=40,VERSION=0.2.9,VM=v… ----- Cheers, Sean -- View this message in context: http://forum.world.st/Launcher-Mac-CI-Broken-Executable-tp4820123p4874227.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 26, 2016

Re: [Pharo-dev] [Vm-dev] re: FFICHeaderExtractor first milestone (for early code reviewers)

by Mariano Martinez Peck

On Tue, Jan 26, 2016 at 8:34 AM, Craig Latta <craig(a)netjam.org> wrote: > > > Nice. I was writing little C programs to tell me various > constants... it sounds like this automates that and keeps the > interaction in Smalltalk. > Yeah, exactly. It is automate that and the result can be stored as "init" methods (one per platform) in the shared pools directly. Also, it will take care of initializing them (searching the correct init method for the current platform) at startup. Note that I called the project FFICHeaderExtractor and not FFICConstantsExtractor. If time allows, I would also like to get info from structs: sizeof and how they are defined internally. That would be yet another feature to let more things to be done via FFI. See https://github.com/marianopeck/FFICHeaderExtractor/issues/1 But that would require some more effort! > > > -C > > -- > Craig Latta > Black Page Digital > postbus 10784 > 1001ET Amsterdam, Netherlands > craig(a)blackpagedigital.com > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > -- Mariano http://marianopeck.wordpress.com

Jan. 26, 2016

Re: [Pharo-dev] monkey error

by Nicolai Hess

2016-01-25 20:31 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > no ideaâ¦ I think is a sthub problem, I need to take a look at it but as > always, Iâm running with other stuffâ¦ but I will try to add a retry when > downloading (thatâs the stupid timeout). > > ah, then there are a couple of random glamour and other tests that fails. > Just a couple. I vote to fix them or disable them :) > It is not only the timeout or randomly failing tests, sometimes the monkey reports a successful validation but the validation report shows "Finished: FAILURE" (there aren't many people fixing/reviewing bugs - much to few for this amount of bug reports, and in the current state, most time is just wasted because you can do the resolving, checking and reviewing again and again and again). I think , fixing this bugtracker validation errors should have the highest priority, so if anyone can help with this, please do. > > Esteban > > > On 25 Jan 2016, at 20:12, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > Fixing bugs (resolve/review/check monkey result) is > > extremly frustrating at the moment. > > > > Anything we can do ? > > >

Jan. 26, 2016

Re: [Pharo-dev] [ANN] FFICHeaderExtractor first milestone (for early code reviewers) [WAS] Can OSProcess functionality be implemented using FFI instead of plugin?

by stepharo

super! Stef Le 25/1/16 23:27, Mariano Martinez Peck a Ã©crit : > Hi guys, > > OK, I have a first working version and so I wanted to share it with you. > > I have not yet the time to start writing the doc since I just finished > the first pass on the code. Tomorrow I will start with the doc. But I > thought some of you may be interested in taking a look even without > formal "doc" (and some feedback/iteration may avoid re-writing docs..). > > If you have no clue what I am talking about, then this summary is for you: > / > / > /----------/ > /When we use FFI to call a certain library it's quite common that we > need to pass as argument certain constants (for example, SIGKILL to > kill()). These constants are defined in C header files and can even > change it's value in different paltforms. / > /These constants also are sometimes defined by the C preprocessor and > so there is not way to get those values from FFI. If you don't have > the value of those constants, you cannot make the FFI call. / > /----------/ > > I have tested the tool in OSX and CentOS using latest Pharo 5.0. It > won't work in Windows right now. As usual, all classes and methods > have comments and there are enough tests. > > At the end, I decided the C program will output a very naive Smalltalk > literal array kind of thingy. The tool then parses that output and > directly creates a init method (which is compiled into the SharedPool > class) for that platform which is then called automatically at startup > (only if initialization is needed). > > As for real examples, I started to write constants for libc: signal.h > (to use kill()) , wait.h (to use wait() famility), fcntl.h (to use ... > xxx()) , and errno.h. You can take a look to the > package 'FFICHeaderExtractor-LibC'. > > Note that for running the tests you need 'cc' findable by path in OSX > and 'gcc' in Unix. > > To load the code in a latest Pharo 5.0, execute: > > Metacello new > baseline: 'FFICHeaderExtractor'; > repository: > 'github://marianopeck/FFICHeaderExtractor:master/repository'; > load. > Any feedback is appreciated. > I will start writing the doc now. > BTW: Big thanks to Eliot Miranda which helped me answering noob > questions and providing useful code and guidelines. > Best, > > > On Sat, Jan 23, 2016 at 1:12 PM, Eliot Miranda > <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > > > Hi Denis, > > On Jan 23, 2016, at 7:30 AM, Denis Kudriashov > <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > >> >> 2016-01-22 22:35 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com >> <mailto:eliot.miranda@gmail.com>>: >> >> Let's measure this. Let's say we have 8 platforms (that's an >> underestimate, because different Linux distributions may have >> different values for certain constants), but 8, which is 4 >> basic platforms times 32- & 64-bits. We have Mac x86 32-bit, >> Mac x64 64-bit, Windows x86 32-bit, Windows x64 64-bit, Linux >> x86 32-bit, Linux ARM 32-bit, Linux x64 64-bit, and soon >> enough there will be more. Further, there may be different >> versions over time. >> >> So each of those initialization methods has >> - 1 slot for the global variable to be assigned >> - 1 slot for the literal value to assign to it >> - 3 bytes of bytecode per initialization for small methods, 4 >> for large methods. Let's say 4. >> >> So the overhead in 32-bits is 12 bytes per constant, and in >> 64-bits is 20 bytes. So the overhead per constant for all >> platforms is 96 bytes per constant in 32-bits and 160 bytes >> per constant for 64-bits. A full system with sockets, files, >> a database connexion etc could easily exceed 100 constants. >> I think it would be nearer 1000. So the overheads are in the >> 10- to 100-k byte range (100k ~= 0.5% of the image) on >> 32-bits. That's low but it's also pure overhead. Every GC >> has to visit them. Every senders and implementors has to >> visit them, but they offer nothing of value. Whereas the >> small parser for whatever notation is used to store the >> constants externally (if they are needed in a given >> deployment) has a small constant overhead; its simple code. >> >> Further, you still need the machinery to export the constants >> to be able to generate these initialization methods. If >> you've got the machinery and you don't need the methods why >> bother to generate the methods? >> >> As the Scots say, many a mickle makes a muckle. >> >> >> Thank's Eliot for such detailed explanation. It makes sense. >> But personally I prefer Smalltalk solution although Smalltalk >> itself is pure overhead comparing to C. > > I can see the draw of the pure Smalltalk. Simplicity and brows > ability. But imagine a tiny headless image deployed on > containers, say 2mb. Now 100kb of initialization code doesn't > look so good :-). Anyway I'm beating a dead horse. Mariano is > generating initialization methods. > > >> My question was raised by Mariano idea to save ston files in >> methods. I think it can reduce problems which you described. >> But then literal array syntax can be more suitable than ston. > > I just want to be clear, I'm neutral about the notation used to > export info from the C file. Liberal array syntax, chunk source > format, ston, xml. It doesn't matter as long as it's convenient > at expressing an attribute dictionary from names to attributes > such as value, size, offset. Don't get hung up on the specific > notation. If one were to go with the external file the only real > requirements are that it be reasonably compact and quick to > parse. That might kill xml but leave plenty of other candidates. > > > _,,,^..^,,,_ (phone) > > > > > -- > Mariano > http://marianopeck.wordpress.com

Jan. 26, 2016

Re: [Pharo-dev] [ANN] FFICHeaderExtractor first milestone (for early code reviewers) [WAS] Can OSProcess functionality be implemented using FFI instead of plugin?

by Max Leske

Yay! > On 25 Jan 2016, at 23:27, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Hi guys, > > OK, I have a first working version and so I wanted to share it with you. > > I have not yet the time to start writing the doc since I just finished the first pass on the code. Tomorrow I will start with the doc. But I thought some of you may be interested in taking a look even without formal "doc" (and some feedback/iteration may avoid re-writing docs..). > > If you have no clue what I am talking about, then this summary is for you: > > ---------- > When we use FFI to call a certain library it's quite common that we need to pass as argument certain constants (for example, SIGKILL to kill()). These constants are defined in C header files and can even change it's value in different paltforms. > These constants also are sometimes defined by the C preprocessor and so there is not way to get those values from FFI. If you don't have the value of those constants, you cannot make the FFI call. > ---------- > > I have tested the tool in OSX and CentOS using latest Pharo 5.0. It won't work in Windows right now. As usual, all classes and methods have comments and there are enough tests. > > At the end, I decided the C program will output a very naive Smalltalk literal array kind of thingy. The tool then parses that output and directly creates a init method (which is compiled into the SharedPool class) for that platform which is then called automatically at startup (only if initialization is needed). > > As for real examples, I started to write constants for libc: signal.h (to use kill()) , wait.h (to use wait() famility), fcntl.h (to use ... xxx()) , and errno.h. You can take a look to the package 'FFICHeaderExtractor-LibC'. > > Note that for running the tests you need 'cc' findable by path in OSX and 'gcc' in Unix. > > To load the code in a latest Pharo 5.0, execute: > > Metacello new > baseline: 'FFICHeaderExtractor'; > repository: 'github://marianopeck/FFICHeaderExtractor:master/repository'; > load. > > Any feedback is appreciated. > > I will start writing the doc now. > > BTW: Big thanks to Eliot Miranda which helped me answering noob questions and providing useful code and guidelines. > > Best, > > > > > > > > On Sat, Jan 23, 2016 at 1:12 PM, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > > Hi Denis, > > On Jan 23, 2016, at 7:30 AM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > >> >> 2016-01-22 22:35 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: >> Let's measure this. Let's say we have 8 platforms (that's an underestimate, because different Linux distributions may have different values for certain constants), but 8, which is 4 basic platforms times 32- & 64-bits. We have Mac x86 32-bit, Mac x64 64-bit, Windows x86 32-bit, Windows x64 64-bit, Linux x86 32-bit, Linux ARM 32-bit, Linux x64 64-bit, and soon enough there will be more. Further, there may be different versions over time. >> >> So each of those initialization methods has >> - 1 slot for the global variable to be assigned >> - 1 slot for the literal value to assign to it >> - 3 bytes of bytecode per initialization for small methods, 4 for large methods. Let's say 4. >> >> So the overhead in 32-bits is 12 bytes per constant, and in 64-bits is 20 bytes. So the overhead per constant for all platforms is 96 bytes per constant in 32-bits and 160 bytes per constant for 64-bits. A full system with sockets, files, a database connexion etc could easily exceed 100 constants. I think it would be nearer 1000. So the overheads are in the 10- to 100-k byte range (100k ~= 0.5% of the image) on 32-bits. That's low but it's also pure overhead. Every GC has to visit them. Every senders and implementors has to visit them, but they offer nothing of value. Whereas the small parser for whatever notation is used to store the constants externally (if they are needed in a given deployment) has a small constant overhead; its simple code. >> >> Further, you still need the machinery to export the constants to be able to generate these initialization methods. If you've got the machinery and you don't need the methods why bother to generate the methods? >> >> As the Scots say, many a mickle makes a muckle. >> >> Thank's Eliot for such detailed explanation. It makes sense. >> But personally I prefer Smalltalk solution although Smalltalk itself is pure overhead comparing to C. > > I can see the draw of the pure Smalltalk. Simplicity and brows ability. But imagine a tiny headless image deployed on containers, say 2mb. Now 100kb of initialization code doesn't look so good :-). Anyway I'm beating a dead horse. Mariano is generating initialization methods. > > >> My question was raised by Mariano idea to save ston files in methods. I think it can reduce problems which you described. >> But then literal array syntax can be more suitable than ston. > > I just want to be clear, I'm neutral about the notation used to export info from the C file. Liberal array syntax, chunk source format, ston, xml. It doesn't matter as long as it's convenient at expressing an attribute dictionary from names to attributes such as value, size, offset. Don't get hung up on the specific notation. If one were to go with the external file the only real requirements are that it be reasonably compact and quick to parse. That might kill xml but leave plenty of other candidates. > > > _,,,^..^,,,_ (phone) > > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Jan. 26, 2016

[ANN] FFICHeaderExtractor first milestone (for early code reviewers) [WAS] Can OSProcess functionality be implemented using FFI instead of plugin?

by Mariano Martinez Peck

Hi guys, OK, I have a first working version and so I wanted to share it with you. I have not yet the time to start writing the doc since I just finished the first pass on the code. Tomorrow I will start with the doc. But I thought some of you may be interested in taking a look even without formal "doc" (and some feedback/iteration may avoid re-writing docs..). If you have no clue what I am talking about, then this summary is for you: *----------* *When we use FFI to call a certain library it's quite common that we need to pass as argument certain constants (for example, SIGKILL to kill()). These constants are defined in C header files and can even change it's value in different paltforms. * *These constants also are sometimes defined by the C preprocessor and so there is not way to get those values from FFI. If you don't have the value of those constants, you cannot make the FFI call. * *----------* I have tested the tool in OSX and CentOS using latest Pharo 5.0. It won't work in Windows right now. As usual, all classes and methods have comments and there are enough tests. At the end, I decided the C program will output a very naive Smalltalk literal array kind of thingy. The tool then parses that output and directly creates a init method (which is compiled into the SharedPool class) for that platform which is then called automatically at startup (only if initialization is needed). As for real examples, I started to write constants for libc: signal.h (to use kill()) , wait.h (to use wait() famility), fcntl.h (to use ... xxx()) , and errno.h. You can take a look to the package 'FFICHeaderExtractor-LibC'. Note that for running the tests you need 'cc' findable by path in OSX and 'gcc' in Unix. To load the code in a latest Pharo 5.0, execute: Metacello new baseline: 'FFICHeaderExtractor'; repository: 'github://marianopeck/FFICHeaderExtractor:master/repository'; load. Any feedback is appreciated. I will start writing the doc now. BTW: Big thanks to Eliot Miranda which helped me answering noob questions and providing useful code and guidelines. Best, On Sat, Jan 23, 2016 at 1:12 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Denis, > > On Jan 23, 2016, at 7:30 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > 2016-01-22 22:35 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Let's measure this. Let's say we have 8 platforms (that's an >> underestimate, because different Linux distributions may have different >> values for certain constants), but 8, which is 4 basic platforms times 32- >> & 64-bits. We have Mac x86 32-bit, Mac x64 64-bit, Windows x86 >> 32-bit, Windows x64 64-bit, Linux x86 32-bit, Linux ARM 32-bit, Linux x64 >> 64-bit, and soon enough there will be more. Further, there may be >> different versions over time. >> >> So each of those initialization methods has >> - 1 slot for the global variable to be assigned >> - 1 slot for the literal value to assign to it >> - 3 bytes of bytecode per initialization for small methods, 4 for large >> methods. Let's say 4. >> >> So the overhead in 32-bits is 12 bytes per constant, and in 64-bits is 20 >> bytes. So the overhead per constant for all platforms is 96 bytes per >> constant in 32-bits and 160 bytes per constant for 64-bits. A full system >> with sockets, files, a database connexion etc could easily exceed 100 >> constants. I think it would be nearer 1000. So the overheads are in the >> 10- to 100-k byte range (100k ~= 0.5% of the image) on 32-bits. That's low >> but it's also pure overhead. Every GC has to visit them. Every senders >> and implementors has to visit them, but they offer nothing of value. >> Whereas the small parser for whatever notation is used to store the >> constants externally (if they are needed in a given deployment) has a small >> constant overhead; its simple code. >> >> Further, you still need the machinery to export the constants to be able >> to generate these initialization methods. If you've got the machinery and >> you don't need the methods why bother to generate the methods? >> >> As the Scots say, many a mickle makes a muckle. > > > Thank's Eliot for such detailed explanation. It makes sense. > But personally I prefer Smalltalk solution although Smalltalk itself is > pure overhead comparing to C. > > > I can see the draw of the pure Smalltalk. Simplicity and brows ability. > But imagine a tiny headless image deployed on containers, say 2mb. Now > 100kb of initialization code doesn't look so good :-). Anyway I'm beating > a dead horse. Mariano is generating initialization methods. > > > My question was raised by Mariano idea to save ston files in methods. I > think it can reduce problems which you described. > But then literal array syntax can be more suitable than ston. > > > I just want to be clear, I'm neutral about the notation used to export > info from the C file. Liberal array syntax, chunk source format, ston, > xml. It doesn't matter as long as it's convenient at expressing an > attribute dictionary from names to attributes such as value, size, offset. > Don't get hung up on the specific notation. If one were to go with the > external file the only real requirements are that it be reasonably compact > and quick to parse. That might kill xml but leave plenty of other > candidates. > > > _,,,^..^,,,_ (phone) > > -- Mariano http://marianopeck.wordpress.com

Jan. 25, 2016

Re: [Pharo-dev] another spotter question

by stepharo

> > Oh wow! I had no idea you click that area to toggle the preview! This is my point :) > > Even with the shift hints. > > At the very least, it needs something more in the shift hints than > just a change in background color!

Jan. 25, 2016