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

Re: [Pharo-dev] NativeBoost: Documentation Suggestion and Question

by Sean P. DeNigris

Igor Stasenko wrote > PaError Pa_OpenDefaultStream(NBExternalAddress * stream ... ) > then your call site will look like following: > streamHandle := NBExternalAddress new. Okay, one step closer. I somewhat randomly guessed to use NBExternalAddress, but didn't have the correct thing in the signature... Igor Stasenko wrote > But hold on, next thing you will stuck with is callback ... hehe :) > ... > for that, again you can just change the function signature and... > put nil. (yes, nil literal) So you're saying the signature would become: nbCall: #(PaError Pa_OpenDefaultStream(NBExternalAddress * stream, ... ulong framesPerBuffer, nil, void * userData)) I made the changes as I understood them, but I'm getting a "generic failure" when I call Pa_OpenDefaultStream. I uploaded the latest changes to the repo... ----- Cheers, Sean -- View this message in context: http://forum.world.st/NativeBoost-Documentation-Suggestion-and-Question-tp4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 13, 2013

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

by Chris Muller

I know nothing about Xtreams but, IMO, this obsession with sterility borders on mental illness. "All sort of un-needed complexity?" That's overstating it a bit, don't you think? So you must really feel stressed that ALL Object's, in fact, have a #name, huh? I admit this seems to push the limits but... what's the point of having any kind of different streams at all then? It's the _differences_ between them that makes composing them useful. Compression, encryption, filtering, sockets, files, circular, etc. You think you'll be able to do all that and get away with all of them having exactly the same API? IMHO working around that, passing extra objects around, sounds more stressful than letting a stream on a _file_ know its filename.. > If it really need it, the application certainly can retrieve the name from a higher level object (a FIleReference, FileDirectory or whatever). How does that solution allow uniformity in stream-using code? On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Yes, a Wrapper would provide the legacy API. > > And yes, the name of a stream should better not be part of the API. > Most stream don't have a name, and adding such API adds all sort of > un-needed complexity. > It's an internal detail that can eventually help for reporting error if > accessible, but nothing more. > > If it really need it, the application certainly can retrieve the name from a > higher level object (a FIleReference, FileDirectory or whatever). > > > 2013/11/13 Chris Muller <asqueaker(a)gmail.com> >> >> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> > It's just a matter of selecting a strategy. I've proposed two: >> > A) create a wrapper class for legacy Stream compatibility selectors >> > B) create extensions for Legacy Stream compatibility selectors >> > My preference goes to A) >> >> By wrappers you mean the Xtreams are the innards doing the work and >> the wrappers providing the legacy API? >> >> This would be a great way to test Xtreams. >> >> > The legacy support MUST be minimal (next nextPut: nextPutAll: peek upTo: >> > ...), otherwise we will import all the cruft in Xtream and would go back >> > to >> > our starting point... >> > Once the minimal support written (a few hours should be enough), we >> > should >> > gradually switch each every legacy Stream usage -> Xtream. >> > >> > An area which require more work is those Streams that have mixed >> > conventions >> > (one portion is interpreted as text, another as binary). >> > In theory that's easy, we just have two streams and they both wrap on a >> > low >> > level binary stream, but that means we have to be very cautious with >> > buffers >> > and caches. >> > >> > Another area of work is usage of ugly selectors like name (we try to >> > access >> > the file name from the Stream API, arghh). Those usages are bad and >> > require >> > a rewrite. >> >> Are you saying a FileStream knowing its #name or #filename is bad? >> >

Nov. 13, 2013

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

by Nicolas Cellier

Yes, a Wrapper would provide the legacy API. And yes, the name of a stream should better not be part of the API. Most stream don't have a name, and adding such API adds all sort of un-needed complexity. It's an internal detail that can eventually help for reporting error if accessible, but nothing more. If it really need it, the application certainly can retrieve the name from a higher level object (a FIleReference, FileDirectory or whatever). 2013/11/13 Chris Muller <asqueaker(a)gmail.com> > On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > It's just a matter of selecting a strategy. I've proposed two: > > A) create a wrapper class for legacy Stream compatibility selectors > > B) create extensions for Legacy Stream compatibility selectors > > My preference goes to A) > > By wrappers you mean the Xtreams are the innards doing the work and > the wrappers providing the legacy API? > > This would be a great way to test Xtreams. > > > The legacy support MUST be minimal (next nextPut: nextPutAll: peek upTo: > > ...), otherwise we will import all the cruft in Xtream and would go back > to > > our starting point... > > Once the minimal support written (a few hours should be enough), we > should > > gradually switch each every legacy Stream usage -> Xtream. > > > > An area which require more work is those Streams that have mixed > conventions > > (one portion is interpreted as text, another as binary). > > In theory that's easy, we just have two streams and they both wrap on a > low > > level binary stream, but that means we have to be very cautious with > buffers > > and caches. > > > > Another area of work is usage of ugly selectors like name (we try to > access > > the file name from the Stream API, arghh). Those usages are bad and > require > > a rewrite. > > Are you saying a FileStream knowing its #name or #filename is bad? > >

Nov. 13, 2013

[pharo-project/pharo-core]

by GitHub

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

Nov. 13, 2013

[pharo-project/pharo-core] 80426c: 30570

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 80426c3280e89d9e72ab38aac1f75f5353560448 https://github.com/pharo-project/pharo-core/commit/80426c3280e89d9e72ab38aa… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-13 (Wed, 13 Nov 2013) Changed paths: A Keymapping-Core.package/KMCategory.class/instance/associating/removeKeymapEntry_.st A Keymapping-Core.package/KMCategory.class/instance/binding/keymapForShortcut_.st A Keymapping-Core.package/KMDispatcher.class/instance/building/keymapForShortcut_.st A Keymapping-Core.package/KMDispatcher.class/instance/building/removeKeyCombination_.st M Keymapping-Core.package/KMStorage.class/definition.st M Keymapping-Core.package/KMStorage.class/instance/accessing/add_.st A Keymapping-Core.package/KMStorage.class/instance/accessing/keymapForShortcut_.st M Keymapping-Core.package/KMStorage.class/instance/accessing/keymaps.st A Keymapping-Core.package/KMStorage.class/instance/accessing/remove_.st M Keymapping-Core.package/KMStorage.class/instance/initialization/initialize.st A Keymapping-Core.package/extension/Morph/instance/removeKeyCombination_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script226.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30570.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30570 12149 Add support for removing a binding https://pharo.fogbugz.com/f/cases/12149 http://files.pharo.org/image/30/30570.zip

Nov. 13, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/Run=run%201,VM=vm,label=linux… 1 regressions found. FileSystem.Tests.Disk.FileHandleTest.testTruncate

Nov. 13, 2013

Jenkins build became unstable: Pharo-2.0-Tests Â» run 1,vm,linux #278

by no-reply＠ci.inria.fr

See <https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/Run=run%201,VM=vm,label=linux…>

Nov. 13, 2013

Re: [Pharo-dev] Instrumenting field accesses with Opal?

by Camille Teruel

On 13 nov. 2013, at 15:18, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > > > YourClass methods do: [ :method | > method ast > forAllNodes: [ :node | node isVariable and: [ node isInstance ] ] > putAfter: [ RFMetalink expression: 'Transcript crShow: ''iv accessed''' ]; > installWrapper ]. > > > > I tried this code but it fails in the latest version of Reflectivity :) Neither in old ones, my mistake :) > First "RFMetalink class(Object)>>doesNotUnderstand: #expression:" Yes it's #fromExpression: > then "A variable node on left side of assignment doesn''t accept metalinks" Indeed For iv assignment, you should put metalinks on the assignment node. So it should be something like that: YourClass methods do: [ :method | method ast forAllNodes: [ :node | node isVariable and: [node isRead and: [ node isInstance ] ] ] putAfter: [ RFMetalink fromExpression: 'Transcript crShow: ''iv read''' ]; forAllNodes: [ :node | node isAssignment and: [ node variable isInstance ] ] putAfter: [ RFMetalink fromExpression: 'Transcript crShow: ''iv written''' ]; installWrapper ] > >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > >

Nov. 13, 2013

Re: [Pharo-dev] Instrumenting field accesses with Opal?

by Andrei Chis

> YourClass methods do: [ :method | > method ast > forAllNodes: [ :node | node isVariable and: [ node isInstance ] ] > putAfter: [ RFMetalink expression: 'Transcript crShow: ''iv accessed''' > ]; > installWrapper ]. > > I tried this code but it fails in the latest version of Reflectivity :) First "RFMetalink class(Object)>>doesNotUnderstand: #expression:" then "A variable node on left side of assignment doesn''t accept metalinks" > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Nov. 13, 2013

Re: [Pharo-dev] Peek

by Sven Van Caekenberghe

On 06 Nov 2013, at 13:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 06 Nov 2013, at 13:20, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> >> On 04 Nov 2013, at 5:12 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> 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 >> >> Yeahâ¦ sooo, I loaded the updated version, great improvement for streams on Latin1 content :D >> >> Maybe itâs just me, but I tested with actual wide source as well (it was as slow as youâd expect), and I think you need a notQuiteSoOptimizedReadInto* which uses the normal Byte -> Wide become: conversion machinery. >> Writing a ZnByteStringBecameWideString handler for every next: (and cousins) call where source may be non-latin1 is a real chore/nasty surprise for those used to dealing with legacy streams/converters... >> You can sort of kinda make up for the performance hit (at least on these sizes) with a faster replace:from:to:with:startingAt: in use after the fact, by using basicAt:put: to the string, thus avoiding converting the replacement value to character. >> >> Cheers, >> Henry >> >> PS: Why is ZnByteStringBecameWideString a notification and not a resumable exception? I would assume those who run into it without a handler would rather have an actual error, than a result where their string has been read up to the first wide charâ¦ > > Henrik, thanks again for the feedback, it is really useful. > > You are right, the ZnByteStringBecameWideString hack was introduced specifically to avoid the become, because benchmarking showed that it took too long. The original user is ZnStringEntity>>#readFrom: > > Now, if you know up front that your string will be wide anyway, then there is #decodeBytesIntoWideString: > > Yes, ZnByteStringBecameWideString should probably be a resumable exception, as not handling it properly will lead to errors. > > I will have to think and reconsider the generality/specificity of the optimisation hack in ZnUTF8Encoder. I got some ideas, but it will take some time. > > At least the code works now, time to process the constructive criticism. === Name: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.28 Author: SvenVanCaekenberghe Time: 13 November 2013, 3:04:00.925461 pm UUID: f104e1ee-7fe5-4a23-a650-197dd9462783 Ancestors: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.27 ZnByteStringBecameWideString is now a resumable Error instead of a Notification (as suggested by henrik sperre johansen); Added ZnByteStringBecameWideString>>#becomeForward convenience method Fixed ZnCharacterReadStream>>#readInto:startingAt:count: to do the actual becomeForward when needed so that clients are not affected === Name: Zinc-Character-Encoding-Tests-SvenVanCaekenberghe.15 Author: SvenVanCaekenberghe Time: 13 November 2013, 3:05:18.26391 pm UUID: 8c41ee29-9906-4626-a9da-cb576980cd4c Ancestors: Zinc-Character-Encoding-Tests-SvenVanCaekenberghe.14 Added a unit test to make sure ZnCharacterReadStream>>#readInto:startingAt:count: does an actual becomeForward when needed === At least the situation is correct now. Sven

Nov. 13, 2013