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

Job offer

by stepharo

Begin forwarded message: From: Georg Heeg <georg(a)heeg.de> Subject: [Esug-list] Looking for Smalltalkers Date: 12 Jan 2016 17:57:27 GMT+1 To: ESUG Mailing list <esug-list(a)lists.esug.org> A customer of ours is looking for two Smalltalkers starting not later as July 1st, 2016, unlimited work contracts. Please contact me for details Georg Heeg Georg Heeg eK, Dortmund und KÃ¶then, HR Dortmund A 12812 Baroper Str. 337, 44227 Dortmund, Germany Tel. +49-3496-214328, Fax +49-231-97599-20 _______________________________________________ Esug-list mailing list Esug-list(a)lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Jan. 12, 2016

Re: [Pharo-dev] Redirect bug in Zinc in the recent Pharo 5 images

by Sven Van Caekenberghe

> On 12 Jan 2016, at 15:05, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Monty, > > Thanks for reporting this issue. > > The problem is that Zn requests http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd using Host: www.oasis-open.org:80 (so with an explicit port) and apparently this server cannot directly deal with that and redirects to the same URL (but without the port) and Zn then does the same thing: ergo, an infinite loop. > > This was probably introduced a while ago when support for HTTPS Connect proxying was added. It will take me a little while to get into why it was added and if/how it can be avoided. I committed the following in #bleedingEdge: === Name: Zinc-HTTP-SvenVanCaekenberghe.444 Author: SvenVanCaekenberghe Time: 12 January 2016, 8:31:50.516464 pm UUID: 231767b6-088c-462b-8c1d-dbcdc9eb5198 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.443 Revert the decision to use #authorityWithPort instead of #authority in ZnHeaders>>#request: A bug reported by Monty shows that some servers are sensitive to the default port being added Another reading of the specs seems to indicate that the default port (80 or 433) is really not needed (but not forbidden either) This might interfere with HTTPS proxying using HTTP CONNECT tunneling but that is very hard to test (see Zinc-HTTP-SvenVanCaekenberghe.437) === All tests remain green and your request now succeeds. But like I said, it is hard to test the proxying, let's hope I didn't break anything. > In any case, this is the first server that causes this ;-) > > Sven > >> On 12 Jan 2016, at 07:00, monty <monty2(a)programmer.net> wrote: >> >> When you try to retrieve this URL with recent Zinc versions, you get a max number of redirects exceeded error: >> >> http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd >> >> This is causing an XMLParser test to fail. But you can retrieve the URL fine in older images (with older versions of Zinc). I tried changing the max number of redirects to something higher, to no avail. Even when allowing hundreds of redirects, I still get the error. >> >

Jan. 12, 2016

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] valid pragma syntax

by Nicolai Hess

2016-01-10 16:57 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Nicolai, > > On Sun, Jan 10, 2016 at 3:16 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> pharo fogbugz issue: 17359 MessageNotUnderstood: receiver of "keywords" >> is nil >> >> >> is this valid pragma syntax: >> >> <apicall: bool 'SetCursorPos' (long long) module: 'user32.dll'> >> > > As others have said this is not a valid pragma. A valid pragma is a > message expression (a message with no receiver) that has only literal > arguments. There is one exception, to accept a variable name for the error > code in a primitive invocation. > > And as Levente has said it is a goal of the new FFI to get rid of the old > syntax you show above. > Thanks Eliot. I think I will wait what Esteban will say to this, he put those classes in the image, maybe he had a plan for the new ffi/apicall syntax > And as Igor Stasenko discovered /any/ C signature can be written as a > literal Array, providing we allow underscores in Symbols (which is a > preference). So for example, the heapsort declaration from the standard C > library: > > int > heapsort(void *base, size_t nel, size_t width, > int (*compar)(const void *, const void *)) > > could be written as a pragma via e.g. > > <ffiCCall: #(int heapsort(void *base, size_t nel, size_t width, int > (*compar)(const void *, const void *)))> > > in which case it is equal to > > <ffiCCall: #(#int #heapsort #( #void #* #base #, #size_t #nel #, > #size_t #width #, #int #( #* #compar ) #( #const #void #*, #const #void > #*)))> > > which, while a massive hack, is pretty neat. The only difficulty in > parsing the above s that void *, is #void #*, not #void #* #,. > > So for me, the natural pragma syntax for the new FFI should be a single > keyword starting with ffi that includes the language with which to parse > the pragma's argument, followed by a literal Array containing the signature > (rather than e.g. a String). I'd also provide a special-purpose > pretty-printer for literal arrays that would be used to pretty-print the > above, e.g. when decompiling. > > This would easily allow extensions such as > > <ffiCcall: #(wchar_t * wcschr(const wchar_t *s, wchar_t c)) arg1is: > #UnicodeString arg2is: Character> > > to guide a marshalling engine in providing automatic checks and > conversions. > > [Slightly OT] > Note that I'm already using this syntax in Alien callbacks because one > thing it does is to normalize the signature, eliminating the significance > of most whitespace (the #*, above being one example where it fails). So a > Callback for heapsort above looks like > > voidstarvoidstarRetint: callbackContext sp: spAlien > <signature: #(int (*)(const void *, const void *)) abi: #IA32> > ^callbackContext wordResult: > (block > value: (Alien forPointer: (spAlien unsignedLongAt: 1)) > value: (Alien forPointer: (spAlien unsignedLongAt: 5))) > > or > voidstarvoidstarRetintARM32: callbackContext sp: spAlien > <signature: #(int (*)(const void *, const void *)) abi: #ARM32> > ^callbackContext wordResult: > (block > value: (Alien forPointer: (spAlien registerAt: 1)) > value: (Alien forPointer: (spAlien registerAt: 2))) > > > Hmmm, if Callback had subclasses for each ABI then the above would become > > IA32Callback methods for signature > voidstarvoidstarRetint: callbackContext sp: spAlien > <signature: #(int (*)(const void *, const void *))> > ^callbackContext wordResult: > (block > value: (Alien forPointer: (spAlien unsignedLongAt: 1)) > value: (Alien forPointer: (spAlien unsignedLongAt: 5))) > > ARM32Callback methods for signatures > voidstarvoidstarRetint: callbackContext sp: spAlien > <signature: #(int (*)(const void *, const void *))> > ^callbackContext wordResult: > (block > value: (Alien forPointer: (spAlien registerAt: 1)) > value: (Alien forPointer: (spAlien registerAt: 2))) > > Much nicer. I shall make it so. > > our (pharo) parser can not parse this (does not recognizes the >> "selector parts" (apicall:module:) right) >> >> Any recommendations how to fix this >> - fix RBParser or >> - change this pragma, for example, like this >> <apicall: #(bool SetCursorPos (long long)) module: 'user32.dll'> >> >> >> nicolai >> > > _,,,^..^,,,_ > best, Eliot > >

Jan. 12, 2016

Re: [Pharo-dev] happy lessons from recent talks

by Richard Sargent

Tudor Girba-2 wrote > Hi, > > I just wanted to share with you a bit of a different perspective on what > we do around here. > > Over the past half a year I gave several talks to some 1k technical people > at industrial events like ArchConf, NDC Oslo and several others. The tour > will continue this year at OOP, ArchConf and a couple of other places. > These are places where people talk about mainstream techniques & > technologies (like Java, JS, C#). For example, ArchConf is a premier > software architecture conference in the US. > > During these sessions, people get to experience Moose and Pharo through > live demos. I use these demos as examples of how humane assessment > (building your own analysis tools) can boost engineering decisions making > in practice. > > I consistently receive the feedback that the live programming > possibilities from Pharo/Moose are impressive. But, more recently, there > is something else worthy of being noted. If in previous years, nobody > heard about what we do, this year I started to get consistently a couple > of persons in the room that have heard something about Pharo/Moose before > the presentation. Excellent! > This is huge. While a couple might not sound like much, you should > remember that information (especially in this technical space) has the > capability of spreading exponentially. What we have done over the past > years starts to show results. We have to keep it up. > > Happy New Year! > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." -- View this message in context: http://forum.world.st/happy-lessons-from-recent-talks-tp4870566p4870941.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 12, 2016

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

by Dimitris Chloupis

Why not "Pharo FFI" ? since it will be the official FFI of Pharo. I also like like lighthouse references like "LightSpeed" , "LightForce" , "LightWave" , "Lighting", "LightHouse" etc. On Tue, Jan 12, 2016 at 5:57 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > People has pointed (and they are right) that the name of the new FFI > front-end is misleading. > So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, for > short) is a better nameâ¦ and to keep packages prox. to regular FFI I was > thinking on rename FFI-NB packages to FFI-Unifiedâ¦ but maybe is better just > to rename them as UFFI or UnifiedFFIâ¦ > what do you think? > > Esteban > > >

Jan. 12, 2016

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

by Torsten Bergmann

Esteban Lorenzano wrote: > People has pointed (and they are right) that the name of the new FFI front-end is misleading. "People" means more than just a single person (me). Glad that I'm not the only one who lamented ;) > So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, for short) is a >better nameâ¦ and to keep packages prox. to regular FFI I was thinking on rename FFI-NB >packages to FFI-Unifiedâ¦ but maybe is better just to rename them as UFFI or UnifiedFFIâ¦ > what do you think? +1 Given that we already have abbreviations in "NB" and "FFI" it's not a problem to go for "UFFI". But "UnifiedFFI" would be fine as well. Damien Pollet >UniFFIed ? Would be funny, but given that some people already have a problem with "SmallTalk" vs. "Smalltalk" I would not use it. Thanks T. << THE HARDEST PART IN PROGRAMMING IS FINDING PROPER NAMES >>

Jan. 12, 2016

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

by Damien Pollet

UniFFIed ? On 12 January 2016 at 17:40, Max Leske <maxleske(a)gmail.com> wrote: > In order of preference: > > 1. UnifiedFFI > 2. FFI-Unified (suggests that there may be multiple FFI implementations) > 3. UFFI (not clear to me that this is an FFI) > > Cheers, > Max > > > On 12 Jan 2016, at 16:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > Hi, > > > > People has pointed (and they are right) that the name of the new FFI > front-end is misleading. > > So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, > for short) is a better nameâ¦ and to keep packages prox. to regular FFI I > was thinking on rename FFI-NB packages to FFI-Unifiedâ¦ but maybe is better > just to rename them as UFFI or UnifiedFFIâ¦ > > what do you think? > > > > Esteban > > > > > > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Jan. 12, 2016

[pharo-project/pharo-core]

by GitHub

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

Jan. 12, 2016

[pharo-project/pharo-core] 980d4d: 50523

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 980d4dfa986e3db8067a7ffc1f4a7b43f6454f91 https://github.com/pharo-project/pharo-core/commit/980d4dfa986e3db8067a7ffc… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-12 (Tue, 12 Jan 2016) Changed paths: M ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/symbolic versions/stable_.st A ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/versions/version082_.st M Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/accessing/calculateChildren.st A Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/accessing/getChildren.st M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree examples/exampleTree1.st M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree examples/exampleTree2.st M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree examples/exampleTreeWithAllItemsFilter.st M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree examples/exampleTreeWithAllItemsSearch.st M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree examples/exampleTreeWithRootFilter.st M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree examples/exampleTreeWithRootSearch.st M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree examples/exampleTreeWithVisibleItemsFilter.st M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree examples/exampleTreeWithVisibleItemsSearch.st A Morphic-Widgets-FastTable.package/FTFunction.class/instance/protocol/disable.st A Morphic-Widgets-FastTable.package/FTFunctionWithField.class/instance/protocol/disable.st A Morphic-Widgets-FastTable.package/FTNilFunction.class/instance/protocol/disable.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/drawing/drawOn_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing/disableFunction.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/geometry/extent_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50522.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50523.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50522.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50523.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A SmartSuggestions.package/SugsGlamourCodeContext.class/README.md A SmartSuggestions.package/SugsGlamourCodeContext.class/definition.st A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/refactoring/sourceTextArea.st A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectedClass.st A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectedMethod.st A SmartSuggestions.package/extension/GLMRubricSmalltalkTextModel/instance/sugsContext.st R System-BasicCommandLineHandler.package/BasicCommandLineHandler.class/class/accessing/helpDescription.st R System-BasicCommandLineHandler.package/BasicCommandLineHandler.class/instance/printing/printHelp.st R Tools-Test.package/DebuggerTest.class/README.md R Tools-Test.package/DebuggerTest.class/definition.st R Tools-Test.package/DebuggerTest.class/instance/testing/testBasic.st A Tools-Test.package/SpecDebuggerTest.class/README.md A Tools-Test.package/SpecDebuggerTest.class/definition.st A Tools-Test.package/SpecDebuggerTest.class/instance/testing/testBasic.st Log Message: ----------- 50523 17355 Rename DebuggerTest to SpecDebuggerTest https://pharo.fogbugz.com/f/cases/17355 17372 New ConfigurationOfFastTable (see description for details) https://pharo.fogbugz.com/f/cases/17372 17378 Improve command line handler documentation and help https://pharo.fogbugz.com/f/cases/17378 17146 Suggestions in the playground--> Error https://pharo.fogbugz.com/f/cases/17146 http://files.pharo.org/image/50/50523.zip

Jan. 12, 2016

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

by Thierry Goubier

2016-01-12 18:08 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-01-12 17:58 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> UFFI reminds me UFO which can be translated like Unified Foreign Objects. >> And it has some relation to Alien name. > > > And objects outside image look really like unidentified flying objects. > It's just address, blob of bytes and they fly outside smalltalk world > :) Let's go outside and watch in the starry night UFFI objects ! Thierry

Jan. 12, 2016