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

Re: [Pharo-dev] Peek

by Sven Van Caekenberghe

On 04 Nov 2013, at 17:12, 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. === Name: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.26 Author: SvenVanCaekenberghe Time: 6 November 2013, 10:09:58.837656 am UUID: dcb21b30-9596-446d-801c-b091cf3f415e Ancestors: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.25 ZnCharacterReadStream and ZnCharacterWriteStream now use the optimized bulk reading/writing methods from ZnCharacterEncoder (#readInto:startingAt:count:fromStream: and #next:putAll:startingAt:toStream: respectively) Fixed a bug in ZnUTF8Encoder>>#optimizedReadInto:startingAt:count:fromStream: Some refactoring and cleanup of ZnUTF8Encoder and ZnByteEncoder Added 2 more unit tests === Name: Zinc-Character-Encoding-Tests-SvenVanCaekenberghe.13 Author: SvenVanCaekenberghe Time: 6 November 2013, 10:11:11.411621 am UUID: 71b503eb-548e-4e2f-b80d-4d2b805bd11e Ancestors: Zinc-Character-Encoding-Tests-SvenVanCaekenberghe.12 Added 2 more unit tests ZnCharacterReadStream and ZnCharacterWriteStream now use the optimized bulk reading/writing methods from ZnCharacterEncoder (#readInto:startingAt:count:fromStream: and #next:putAll:startingAt:toStream: respectively) Fixed a bug in ZnUTF8Encoder>>#optimizedReadInto:startingAt:count:fromStream: Some refactoring and cleanup of ZnUTF8Encoder and ZnByteEncoder === > 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

[pharo-project/pharo-core]

by GitHub

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

Nov. 6, 2013

[pharo-project/pharo-core] 8494bd: 20626

by GitHub

Branch: refs/heads/2.0 Home: https://github.com/pharo-project/pharo-core Commit: 8494bd332d81ef76db9658c071e7628f109c51b1 https://github.com/pharo-project/pharo-core/commit/8494bd332d81ef76db9658c0… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-06 (Wed, 06 Nov 2013) Changed paths: A Kernel.package/ProtoObject.class/instance/executeMethod..st M Kernel.package/ProtoObject.class/methodProperties.json M ScriptLoader20.package/ScriptLoader.class/instance/commentForCurrentUpdate.st A ScriptLoader20.package/ScriptLoader.class/instance/script599.st A ScriptLoader20.package/ScriptLoader.class/instance/update20626.st M ScriptLoader20.package/ScriptLoader.class/methodProperties.json Log Message: ----------- 20626 12071 #executeMethod: not in Pharo https://pharo.fogbugz.com/f/cases/12071

Nov. 6, 2013

Re: [Pharo-dev] Feature request poll

by Goubier Thierry

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

Re: [Pharo-dev] No decompile string at all, bad idea?

by Max Leske

On 06.11.2013, at 08:57, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 06 Nov 2013, at 08:53, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 06.11.2013, at 08:05, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On 05 Nov 2013, at 20:37, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> >>>> Hi. From what I understand you removed the old Compiler but yet Opal does not support compiling. Also, #sourceCode was changed etc... >>>> That means that there is no way to see the decompiled string of a method? >>> >>> Yes. >>> >>>> Which means I cannot deploy and image without sources and then browse/debug/inspect/write pharoDebug.log etc because we don't have even the decompile string??? >>> >>> Exactly. But this is just temporary, .sources and .changes will go away in Pharo4 and there will be just a .pharo4 image file. >> >> By âtemporaryâ do you mean decompilation will come back? >> > No, we will have a high-level representation of Methods that replace (from the standpoint of reflection) the incomplete bytecode representation, Ok, good to know. > >>> >>>> Serializing compiled methods is not fun either since we cannot decompile it after... >>>> >>> >>> You can embedd the source into the method before serialising. >> >> That means storing redundant information though (if the user is only interested in functionality) and that will increase file size, and serialization/materalzation time. So itâs not an ideal situation. > > The thing is that we can either not move or move step by step taking (sometimes) into account that things are sub-optimal for a little while. I agree that thatâs sometimes necessary. > > You can envision the current implementation as a peak on a map: itâs a very good local optimum. But *Much* better is possible. Maybne a local metaphor: We are in the Gurten now, you can > not reach the Eiger without going down for a while. Haha :) nice! That means weâll have to figure something out for Fuel to work with not installed compiled methods in 3.0. Thanks for the explanation. > > Marcus

Nov. 6, 2013

Re: [Pharo-dev] No decompile string at all, bad idea?

by Marcus Denker

On 06 Nov 2013, at 08:53, Max Leske <maxleske(a)gmail.com> wrote: > > On 06.11.2013, at 08:05, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 05 Nov 2013, at 20:37, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >>> Hi. From what I understand you removed the old Compiler but yet Opal does not support compiling. Also, #sourceCode was changed etc... >>> That means that there is no way to see the decompiled string of a method? >> >> Yes. >> >>> Which means I cannot deploy and image without sources and then browse/debug/inspect/write pharoDebug.log etc because we don't have even the decompile string??? >> >> Exactly. But this is just temporary, .sources and .changes will go away in Pharo4 and there will be just a .pharo4 image file. > > By âtemporaryâ do you mean decompilation will come back? > No, we will have a high-level representation of Methods that replace (from the standpoint of reflection) the incomplete bytecode representation, >> >>> Serializing compiled methods is not fun either since we cannot decompile it after... >>> >> >> You can embedd the source into the method before serialising. > > That means storing redundant information though (if the user is only interested in functionality) and that will increase file size, and serialization/materalzation time. So itâs not an ideal situation. The thing is that we can either not move or move step by step taking (sometimes) into account that things are sub-optimal for a little while. You can envision the current implementation as a peak on a map: itâs a very good local optimum. But *Much* better is possible. Maybne a local metaphor: We are in the Gurten now, you can not reach the Eiger without going down for a while. Marcus

Nov. 6, 2013

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

by Max Leske

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

Re: [Pharo-dev] No decompile string at all, bad idea?

by Max Leske

On 06.11.2013, at 08:05, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 05 Nov 2013, at 20:37, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> Hi. From what I understand you removed the old Compiler but yet Opal does not support compiling. Also, #sourceCode was changed etc... >> That means that there is no way to see the decompiled string of a method? > > Yes. > >> Which means I cannot deploy and image without sources and then browse/debug/inspect/write pharoDebug.log etc because we don't have even the decompile string??? > > Exactly. But this is just temporary, .sources and .changes will go away in Pharo4 and there will be just a .pharo4 image file. By âtemporaryâ do you mean decompilation will come back? > >> Serializing compiled methods is not fun either since we cannot decompile it after... >> > > You can embedd the source into the method before serialising. That means storing redundant information though (if the user is only interested in functionality) and that will increase file size, and serialization/materalzation time. So itâs not an ideal situation. > > Marcus > > > >

Nov. 6, 2013

[pharo-project/pharo-core]

by GitHub

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

Nov. 6, 2013

[pharo-project/pharo-core] 1c0119: 30548

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 1c0119dc95105dd331ce47309c7422ebaff20562 https://github.com/pharo-project/pharo-core/commit/1c0119dc95105dd331ce4730… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-05 (Tue, 05 Nov 2013) Changed paths: M Files.package/RemoteString.class/instance/accessing/fileStream.st M Files.package/RemoteString.class/instance/accessing/string.st M Files.package/RemoteString.class/instance/private/string_onFileNumber_.st M Kernel.package/CompiledMethod.class/instance/source code management/putSource_inFile_withPreamble_.st A Kernel.package/ProtoObject.class/instance/executing/executeMethod_.st M Network-Kernel.package/SocketStream.class/instance/stream in/upTo_.st A NetworkTests.package/SocketStreamTest.class/instance/stream protocol/testUpToSmallInteger.st A NetworkTests.package/SocketStreamTest.class/instance/stream protocol/testUpToWithByteArray.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script203.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30548.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Support.package/ChangesLog.class/instance/logging/logChange_.st M System-Support.package/ChangesLog.class/instance/private/assureStartupStampLogged.st M Traits.package/TClassDescription.class/instance/filein%2Fout/classComment_stamp_.st Log Message: ----------- 30548 12074 Do not check if SourceFiles is nil https://pharo.fogbugz.com/f/cases/12074 12071 #executeMethod: not in Pharo https://pharo.fogbugz.com/f/cases/12071 2895 SocketStream not robuts against integer https://pharo.fogbugz.com/f/cases/2895 http://files.pharo.org/image/30/30548.zip

Nov. 6, 2013