November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Feature request poll

by Janko MivÅ¡ek

Hi Kilon, Dne 06. 11. 2013 12:00, piÅ¡e kilon alios: > I can only speak on behalf of newcomers as I am a newcomer myself, that > I dont care if Pharo is smalltalk, a dialect, a byproduct , a hybrid, > alien technology. But you found Pharo because you were firstly interested in Smalltalk? If Pharo wouldn't be Smalltalk, would you still found it the same way as you did? Best regards Janko What I care is that is well supported (bug wise), > friendly community (forums), actively developed (updates/ bug fixes), > stable enough, a breath of fresh air (who wants to use the same stuff) > and sufficiently documented. See what I did there I did not even mention > the language nor the environment. > > I am happy that Pharo is all these things, the fact that is smalltalk or > a dialect of it, is just a happy accident ;) > > > On Wed, Nov 6, 2013 at 10:17 AM, Goubier Thierry <thierry.goubier(a)cea.fr > <mailto:thierry.goubier@cea.fr>> wrote: > > Don't even need to follow the link to guess where that comes from :):):) > > The text transcription: > http://www.epicure.demon.co.__uk/whattheromans.html > <http://www.epicure.demon.co.uk/whattheromans.html> > > Thierry > > Le 06/11/2013 01:28, Paul DeBruicker a Ã©crit : > > For whomever wonders what "what have the romans ever done for > us" is about > watch: > > http://www.youtube.com/watch?__v=9foi342LXQE > <http://www.youtube.com/watch?v=9foi342LXQE> > > > you can stop around 2:10 > > > > -- > View this message in context: > http://forum.world.st/Feature-__request-poll-__tp4718993p4719475.html > <http://forum.world.st/Feature-request-poll-tp4718993p4719475.html> > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Nov. 6, 2013

Re: [Pharo-dev] Feature request poll

by kilon alios

I can only speak on behalf of newcomers as I am a newcomer myself, that I dont care if Pharo is smalltalk, a dialect, a byproduct , a hybrid, alien technology. What I care is that is well supported (bug wise), friendly community (forums), actively developed (updates/ bug fixes), stable enough, a breath of fresh air (who wants to use the same stuff) and sufficiently documented. See what I did there I did not even mention the language nor the environment. I am happy that Pharo is all these things, the fact that is smalltalk or a dialect of it, is just a happy accident ;) On Wed, Nov 6, 2013 at 10:17 AM, Goubier Thierry <thierry.goubier(a)cea.fr>wrote: > Don't even need to follow the link to guess where that comes from :):):) > > The text transcription: http://www.epicure.demon.co.uk/whattheromans.html > > Thierry > > Le 06/11/2013 01:28, Paul DeBruicker a Ã©crit : > > For whomever wonders what "what have the romans ever done for us" is about >> watch: >> >> http://www.youtube.com/watch?v=9foi342LXQE >> >> >> you can stop around 2:10 >> >> >> >> -- >> View this message in context: http://forum.world.st/Feature-request-poll- >> tp4718993p4719475.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >> > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >

Nov. 6, 2013

[pharo-project/pharo-core] 3b10b0: 30549

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 3b10b06606dd5f379fca80406f4efa225df8ad8d https://github.com/pharo-project/pharo-core/commit/3b10b06606dd5f379fca8040… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-06 (Wed, 06 Nov 2013) Changed paths: A Deprecated30.package/extension/DateAndTime/instance/secondsSinceMidnight.st A Deprecated30.package/extension/ImageMorph/instance/image.st A Deprecated30.package/extension/ImageMorph/instance/newForm_.st A Deprecated30.package/extension/ImageMorph/instance/setNewImageFrom_.st A Deprecated30.package/extension/KMDispatcher/instance/on_do_.st A Deprecated30.package/extension/MCPackage/instance/packageInfo.st A Deprecated30.package/extension/MCPackageManager/instance/packageInfo.st A Deprecated30.package/extension/MCScriptDefinition/instance/packageInfo.st A Deprecated30.package/extension/MCServerCredentials/class/user_hasPassword_.st A Deprecated30.package/extension/Morph/instance/hasTranslucentColor.st A Deprecated30.package/extension/NewListModel/instance/whenSelectionIndexChanged_.st A Deprecated30.package/extension/Time/class/primSecondsClock.st R Kernel.package/DateAndTime.class/instance/private/secondsSinceMidnight.st R Kernel.package/Time.class/class/primitives/primSecondsClock.st R Keymapping-Core.package/KMDispatcher.class/instance/building/on_do_.st R Monticello.package/MCPackage.class/instance/accessing/packageInfo.st R Monticello.package/MCPackageManager.class/instance/accessing/packageInfo.st R Monticello.package/MCScriptDefinition.class/instance/accessing/packageInfo.st R Monticello.package/MCServerCredentials.class/class/instance creation/user_hasPassword_.st R Morphic-Base.package/ImageMorph.class/instance/deprecated/image.st R Morphic-Base.package/ImageMorph.class/instance/deprecated/newForm_.st R Morphic-Base.package/ImageMorph.class/instance/deprecated/setNewImageFrom_.st R Morphic-Core.package/Morph.class/instance/accessing/hasTranslucentColor.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script204.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30549.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Spec-Core.package/NewListModel.class/instance/protocol-events/whenSelectionIndexChanged_.st Log Message: ----------- 30549 12078 Move more deprecated methods to Deprecated30 package https://pharo.fogbugz.com/f/cases/12078 http://files.pharo.org/image/30/30549.zip

Nov. 6, 2013

[pharo-project/pharo-core]

by GitHub

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

Nov. 6, 2013

Re: [Pharo-dev] TextAttribute, TextAction and TextDoIt or TextURL: not working

by phil＠highoctane.be

Aaaah ;-) Hypertext abilities: a must have, especially since we'll have that super AST-style source code thingy in Pharo4. --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Wed, Nov 6, 2013 at 11:22 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 5 November 2013 22:56, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > >> ,Ooooohhh!!!! >> >> I guess I'll restart work on that old 1.3-based project of mine :-) >> >> Well, well,this opens a lot of doors! (including doc comments with links >> inside them for clickable cross refs, like we had in squeak) >> >> Now, it is going to be used with Tx stuff ? >> >> Phil >> > > Short answer: no. > Long answer: we looking forward to provide similar (or even better :) ) > functionality. > > > -- > Best regards, > Igor Stasenko. >

Nov. 6, 2013

Re: [Pharo-dev] TextAttribute, TextAction and TextDoIt or TextURL: not working

by Igor Stasenko

On 5 November 2013 22:56, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > ,Ooooohhh!!!! > > I guess I'll restart work on that old 1.3-based project of mine :-) > > Well, well,this opens a lot of doors! (including doc comments with links > inside them for clickable cross refs, like we had in squeak) > > Now, it is going to be used with Tx stuff ? > > Phil > Short answer: no. Long answer: we looking forward to provide similar (or even better :) ) functionality. -- Best regards, Igor Stasenko.

Nov. 6, 2013

HDTestReport improvements: please integrate

by Max Leske

Iâve made a few minor improvements to HDTestReport with the following effects: - progress log will now print end of suite and the stream will be properly closed - progress log will print the start of the case *before* the case starts (at the moment that happens after the case has run. The problem is of course that if the VM crashes during that test you can not find out which test caused the crash) Iâd very much appreciate it if someone could install these changes on Jenkins because I need them to debug the VM SegFaults that appear during the Fuel tests. Cheers, Max

Nov. 6, 2013

Re: [Pharo-dev] NBOpenGL VM crash.

by Igor Stasenko

According to dump, it crashes during call to: 0x21d8c8 I NBWndClassEx class>unregister:instance: 0x10f7e7cc: a(n) NBWndClassEx class the reason could be that you passing wrong handle which not exists (or was existed in previous image session but invalid now). Not much else i can say without having image and trying myself. On 6 November 2013 03:42, Ronie Salgado <roniesalg(a)gmail.com> wrote: > I'm trying to use the latest version of NBOpenGL in Windows in Pharo 3.0. > First I'm receiving a "Not suitable implementation" error message. This > can be solved by adding the following at the class side of > NBWin32GLContextDriver. > > NBWin32GLContextDriver>>supportsCurrentPlatform > ^ NativeBoost platformId = NativeBoostConstants win32PlatformId > > Then, trying the following Roassal3D example produces a VM crash: > > R3Example new city > > Attached is the crash.dmp file. Currently, we are using an old pharo image > for developing Roassal3D under windows. > > Greetings, > Ronie Salgado > -- Best regards, Igor Stasenko.

Nov. 6, 2013

Re: [Pharo-dev] Peek

by Sven Van Caekenberghe

On 04 Nov 2013, at 22:25, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > That's great! > Remembering that commit message was part of the reason for benching, was sort of disappointed there was no significant difference between Zn in 2.0 and latest 3.0... > > I guess with the amount of hacks accumulating, it is indeed turning into a worthy successor of MultiByteFileStream ;) Bah, the hacking is limited to one method ( #optimizedReadInto:startingAt:count:fromStream: ) and the readable version is still present and used ( #originalReadInto:startingAt:count:fromStream: ). It is encapsulated and the rest of the code remains quite clear. > Cheers, > Henry > > P.S: If you want another delightful one in the same vein (both from WTFy-ness and perf improvement POV), take a gander at UTF16TextConverter >> nextPutByteString:toStream: Pretty confusing ! BTW, do we still need UTF16 support ? For those encodings that we still want to support in the future, we should have new and more principled implementations under ZnCharacterEncoder. That is, if we ever want to fase out TextConverter. > On Mon, Nov 4, 2013 at 5:12 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Henrik, > > Great writeup, thanks ! > > (more inline) > > On 04 Nov 2013, at 11:58, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > > On 04 Nov 2013, at 9:57 , Diego Lont <diego.lont(a)delware.nl> wrote: > > > >> Working on Petit Delphi we found a strange implementation for asPetitStream: > >> Stream>asPetitStream > >> ^ self contents asPetitStream > >> > >> Further investigation showed that the basic peek was not fast enough for Petit Parser, as it is used a lot. So it implemented a "improved unchecked peek": > >> PPStream>peek > >> "An improved version of peek, that is slightly faster than the built in version." > >> ^ self atEnd ifFalse: [ collection at: position + 1 ] > >> > >> PPStream>uncheckedPeek > >> "An unchecked version of peek that throws an error if we try to peek over the end of the stream, even faster than #peek." > >> ^ collection at: position + 1 > >> > >> But in my knowledge a basic peek should be fast. The real problem is the peek in the underlying peek: > >> PositionableStream>peek > >> "Answer what would be returned if the message next were sent to the > >> receiver. If the receiver is at the end, answer nil." > >> > >> | nextObject | > >> self atEnd ifTrue: [^nil]. > >> nextObject := self next. > >> position := position - 1. > >> ^nextObject > >> > >> That actually uses "self next". The least thing one should do is to cache the next object. But isn't there a primitive for peek in a file stream? Because al overriding peeks of PositionableStream have basically the same implementation: reading the next and restoring the state to before the peek (that is slow). So we would like to be able to remove PPStream without causing performance issues, as the only added method is the "improved peek". > >> > >> Stephan and Diego > > > > If you are reading from file, ZnCharacterStream should be a valid alternative. > > If not, ZnBufferedReadStream on an internal collection stream also does peek caching. > > > > Beware with files though; itâs better to bench the overall operation for different alternatives. > > F.ex, ZnCharacterStream is much faster than the standard Filestream for peek: > > > > cr := ZnCharacterReadStream on: 'PharoDebug.log' asFileReference readStream binary. > > [cr peek] bench. '49,400,000 per second.' > > cr close. > > > > FileStream fileNamed: 'PharoDebug.log' do: [:fs | [fs peek] bench] '535,000 per second.â > > > > but has different bulk reads characteristics (faster for small bulks, slower for large bulks, crossover-point at around 1k chars at once); > > (The actual values are of course also dependent on encoder/file contents, those given here obtained with UTF-8 and a mostly/all ascii text file) > > > > [cr := ZnCharacterReadStream on: ('PharoDebug.log' asFileReference readStream binary ) readStream. > > cr next: 65536; close] bench '105 per second.' '106 per second.â > > Well, I just realised that ZnCharacterReadStream and ZnCharacterWriteStream did not yet make use of the optimisations that I did for ZnCharacterEncoding some time ago. More specifically, they were not yet using #next:putAll:startingAt:toStream: and #readInto:startingAt:count:fromStream: which are overwritten for ZnUTF8Encoder with (super hacked) versions that assume most of the input will be ASCII (a reasonable assumption). > > I am still chasing a bug, but right now: > > [ (ZnCharacterReadStream on: ('timezones.json' asFileReference readStream binary)) > next: 65536; close ] bench. > > "135 per second.â BEFORE > "3,310 per second.â AFTER > > But of course the input file is ASCII, so YMMV. > > Iâll let you know when I commit this code. > > Sven > > > [FileStream fileNamed: 'PharoDebug.log' do: [:fs | fs next: 65536] > > ] bench '176 per second.â > > > > If you use a StandardFilestream set to binary ( which has less overhead for binary nextâs compared to the MultiByteFileStream returned by asFileReference readStream)as the base stream instead, , the same general profile holds true, but with a crossover around 2k characters. > > > > TL;DR: Benchmark the alternatives. The best replacement option depends on your results. Appropriately (according to source and actual use) set up Zn-streams are probably your best bet. > > > > Cheers, > > Henry > > >

Nov. 6, 2013

Re: [Pharo-dev] Bug? AdditionalMethodState suddenly stores Associations

by Max Leske

https://pharo.fogbugz.com/f/cases/12077/MNU-in-AdditionalMethodState-analog… On 06.11.2013, at 08:53, Max Leske <maxleske(a)gmail.com> wrote: > Thanks Marcus. Iâll open a bug report. > > On 06.11.2013, at 08:14, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 05 Nov 2013, at 19:48, Max Leske <maxleske(a)gmail.com> wrote: >> >>> I discovered that AdditionalMethodState now (sometimes) stores Associations, not only Pragmas and Messages. That seems to work fine so fare but leads to an exception if #analogousCodeTo: is sent to a state which stores an Association. >>> >> I think this is the case when the method stored general properties (non-source visible). >> >> see propertyValueAt:put: >> >>> Can someone please confirm that this is a bug? >>> >> >> >> I guess the bug is that analogousCodeTo: should handle the properties correctly. I think just ignoring them would be fine, as they >> are not part of code, but meta. >> >> Marcus >

Nov. 6, 2013