April 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Fixes to External Pharo Projects

by Esteban Lorenzano

individual package in the repo. > On 27 Apr 2015, at 16:13, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > How do we commit fixes to e.g. Tx? Just commit the individual packages to the > Tx repo? Commit a slice there? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Fixes-to-External-Pharo-Projects-tp4822177.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

April 27, 2015

Re: [Pharo-dev] [NB] NBExternalArray not working for complex types?

by Henrik Johansen

> On 26 Apr 2015, at 7:29 , Max Leske <maxleske(a)gmail.com> wrote: > > Hi guys > > I have a problem with NBExternalArray. AFAICT the generated assembly should be able to handle arbitrary elements in the array (as long as they are all of the same type). The operations required to read / write an element are given by the external type specified for the collection (e.g âcharâ or âintâ). All of this works wonderfully for char, int, NBExternalAddress etc. But Iâm trying to get it working for strings. So here is the code that I would expect to work: > > arrayClass := NBExternalArray anonymousSubclassInitElementType: 'String'. > array := arrayClass new: 1. > array at: 1 put: âfoo'. > array at: 1. ââ> should procude âfooâ, but produces arbitrary stringsâ > > I can make it work with NBExternalAddress of course but I donât want to if I can avoid it. > > Iâd appreciate it if someone (Nicolai?) could take a look at NBExternalArray>>emitRead / emitWrite and see if thereâs an easy solution. Especially for strings I donât think it should be too hard since all thatâs needed is already present in the string handling facilities. > > Cheers, > Max There's a solution, but I doubt you could call it simple. NBExternalArray is meant to hold const sized objects, so is allocated with the proper amount of slots up front. If you want it to hold pointers to variably sized objects (like strings), since we can't pin the objects, they need to be copied (well, would have to do that anyways for Strings, which need it'd need to do dynamic allocation (and freeing when appropriate), so emitWrite would become quite a bit more complicated, + necessary object finalization would have to occur. You *can* work around it, by using an element type that is externally allocated, but it adds quite a bit of boilerplate, here's the workspace PoC code: string := 'herruâ¬'. bytes := ZnUTF8Encoder new encodeString: string. mem := NativeBoost allocate: bytes size + 1. NativeBoost memCopy: bytes to: mem size: bytes size. arrClass := NBExternalArray anonymousSubclassInitElementType: 'char *'. arr := arrClass new: 1. arr at: 1 put: mem. ZnUTF8Encoder new decodeBytes: (arr at:1) readString asByteArray Cheers, Henry

April 27, 2015

Fixes to External Pharo Projects

by Sean P. DeNigris

How do we commit fixes to e.g. Tx? Just commit the individual packages to the Tx repo? Commit a slice there? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Fixes-to-External-Pharo-Projects-tp4822177.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 27, 2015

Tx Pass

by Sean P. DeNigris

Just like Bloc (which has *great* class comments), I think it's crucial to document the high level design decisions in Tx. I did a first pass and noted some initial impressions... Design Questions: - TxModel - what is the advantage of a double linked list vs the old Text implementation? - TxLayoutViewMorph vs. TxTextEditorMorph - I'm not clear on the purpose/relationship/pattern here? Implementation Questions: - TxBasicSpan#< seems overly complex. Why two-way searching. Was it the result of profiling? Intuition? Random? - TxTextEditorMorph>>#openInWindowWithText: says not part of API, but this code is pretty much the only way to use it for now, right? - applyAttribute:to: sends an unimplemented message, but I'm not sure what should be done here - Why no strike fonts? Why is Verdana commented out in TxFontAttribute class>>#defaultValue? - TxLayoutViewMorph class>>#text: sends #asTxModel to argument, but TxTextEditorMorph doesn't. Which one is right? I think there's not much harm in sending it in both to make it a bit easier for users... - TxBasicViewMorph>>#fullDrawOnAthensCanvas: checks if fullBounds are visible on canvas, then checks #bounds again. Are both necessary? Tx already seems very usable! I'm starting to play with it in one of my projects... I've been dreaming about this for a long time :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Tx-Pass-tp4822173.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 27, 2015

[pharo-project/pharo-core]

by GitHub

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

April 27, 2015

[pharo-project/pharo-core] be7cf0: 50012

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: be7cf01dd74bac75522c56f450d4842156848933 https://github.com/pharo-project/pharo-core/commit/be7cf01dd74bac75522c56f4… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-04-27 (Mon, 27 Apr 2015) Changed paths: M AsmJit-Extension.package/extension/Integer/instance/isByte.st M AsmJit-Operands.package/AJImmediate.class/instance/testing/isInt32.st M Balloon.package/ShortIntegerArray.class/instance/accessing/at_put_.st M Balloon.package/ShortIntegerArray.class/instance/private/pvtAt_put_.st M Collections-Native.package/ByteArray.class/instance/accessing/indexOf_startingAt_.st M Collections-Sequenceable.package/Interval.class/instance/accessing/at_.st M Collections-Streams.package/PositionableStream.class/instance/positioning/position_.st M FreeType.package/FreeTypeFont.class/instance/measuring/getLinearWidthOf_.st M FreeType.package/FreeTypeFont.class/instance/measuring/getWidthOf_.st M FreeType.package/FreeTypeFont.class/instance/measuring/linearKerningLeft_right_.st M FreeType.package/FreeTypeGlyphRenderer.class/instance/private/renderGlyph_depth_subpixelPosition_font_.st M FreeType.package/FreeTypeSubPixelAntiAliasedGlyphRenderer.class/instance/rendering/renderStretchedGlyph_depth_subpixelPosition_font_.st M Graphics-Primitives.package/BitBlt.class/instance/copying/copyBits.st M Kernel.package/InstructionStream.class/instance/decoding/interpretNextSistaV1InstructionFor_.st M Kernel.package/Object.class/instance/accessing/at_put_.st M Kernel.package/Object.class/instance/accessing/basicAt_put_.st M Kernel.package/Process.class/instance/accessing/priority_.st M Morphic-Base.package/MenuMorph.class/instance/construction/addToggle_target_selector_getStateSelector_enablementSelector_argumentList_.st M Morphic-Widgets-List.package/SimpleHierarchicalListMorph.class/instance/event handling/itemFromPoint_.st M Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/accessing/itemFromPoint_.st M Morphic-Widgets-Pluggable.package/PluggableMultiColumnListMorph.class/instance/accessing/itemFromPoint_.st M Morphic-Widgets-Pluggable.package/PluggableTabBarMorph.class/instance/actions/mouseDown_.st M Morphic-Widgets-Tree.package/MorphTreeMorph.class/instance/events-processing/scrollerSubMorphFromPoint_.st M Morphic-Widgets-Windows.package/StandardWindow.class/instance/controls/title.st M Morphic-Widgets-Windows.package/StandardWindow.class/instance/controls/title_.st M Morphic-Widgets-Windows.package/WindowAnnouncement.class/README.md M Morphic-Widgets-Windows.package/WindowClosed.class/README.md M Morphic-Widgets-Windows.package/WindowLabelled.class/README.md M Morphic-Widgets-Windows.package/WindowMoved.class/README.md M Morphic-Widgets-Windows.package/WindowOpened.class/README.md M Morphic-Widgets-Windows.package/WindowResizing.class/README.md M Morphic-Widgets-Windows.package/WindowScrolling.class/README.md M Multilingual-OtherLanguages.package/ShiftJISTextConverter.class/instance/conversion/nextPut_toStream_.st M Multilingual-OtherLanguages.package/extension/Unicode/class/isUnifiedKanji_.st M Network-UUID.package/extension/String/instance/asAlphaNumeric_extraChars_mergeUID_.st A RPackage-Core.package/RPackage.class/instance/accessing/classes.st A RPackage-Core.package/RPackage.class/instance/accessing/definedClassNames.st A RPackage-Core.package/RPackage.class/instance/accessing/definedClasses.st A RPackage-Core.package/RPackage.class/instance/accessing/methods.st A RPackage-Core.package/RPackage.class/instance/accessing/orderedClasses.st A RPackage-Core.package/RPackage.class/instance/accessing/selectors.st R RPackage-Core.package/RPackage.class/instance/all accessing/classes.st R RPackage-Core.package/RPackage.class/instance/all accessing/definedClassNames.st R RPackage-Core.package/RPackage.class/instance/all accessing/definedClasses.st R RPackage-Core.package/RPackage.class/instance/all accessing/methods.st R RPackage-Core.package/RPackage.class/instance/all accessing/orderedClasses.st R RPackage-Core.package/RPackage.class/instance/all accessing/selectors.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script620.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script621.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50011.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50012.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Platforms.package/Win32Platform.class/instance/accessing/virtualKey_.st M System-Support.package/SmalltalkImage.class/instance/image%2C changes names/imageFile.st M Text-Core.package/RunArray.class/instance/accessing/at_put_.st Log Message: ----------- 50012 15395 Cleanup #1: Lots of little things https://pharo.fogbugz.com/f/cases/15395 15401 MessageNotUnderstood: Association>>translated https://pharo.fogbugz.com/f/cases/15401 15400 comment window announcement classes https://pharo.fogbugz.com/f/cases/15400 http://files.pharo.org/image/50/50012.zip

April 27, 2015

sometimes Shout changes the selection during styling

by Andrei Chis

Hi, In the glamour debugger that we use in moose we are now having the following problem: - the selection of a PluggableTextMorph is, quite randomly , changed during styling. If I revert the fix for issue 15240 <https://pharo.fogbugz.com/f/cases/15240> then it works ok. Also if I change in SHTextStyler>>#styleInBackgroundProcess: from sem waitTimeoutSeconds: 5. view ifNotNil: [ view stylerStyledInBackground: text ] to: (sem waitTimeoutSeconds: 5) ifFalse: [ view ifNotNil: [ view stylerStyledInBackground: text ] ] it works ok. In the second snippet we only do the styling if the styler completed. If I look at the senders of styleInBackgroundProcess: there is another strange issue. First PluggableTextMorph>>#setText: calls either style: or styleInBackgroundProcess:, depending in the size of the text. Then, PluggableTextMorph>>#setText: calls PluggableTextMorph>>#setTextBasic:, which calls PluggableTextMorph>>#hasUnacceptedEdits: which in turn calls again styleInBackgroundProcess:. So when you set the text if the size of the text is small Shout will try to style the text with and without a background process. If you call hasUnacceptedEdits: manually when initializing the morph then three processes will be started for doing the styling. Removing the calls to styleInBackgroundProcess: from PluggableTextMorph>>#hasUnacceptedEdits: and PluggableTextMorph>>#basicHasUnacceptedEdits:. also solves the problem with the changing selection. Cheers, Andrei

April 27, 2015

Re: [Pharo-dev] CI Still Down

by Sean P. DeNigris

Marcus Denker-4 wrote > It has been restarted Thanks, Marcus :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/CI-Still-Down-tp4821894p4822113.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 27, 2015

Re: [Pharo-dev] [NB] NBExternalArray not working for complex types?

by Nicolai Hess

Hi Max 2015-04-26 19:29 GMT+02:00 Max Leske <maxleske(a)gmail.com>: > Hi guys > > I have a problem with NBExternalArray. AFAICT the generated assembly > should be able to handle arbitrary elements in the array (as long as they > are all of the same type). The operations required to read / write an > element are given by the external type specified for the collection (e.g > âcharâ or âintâ). All of this works wonderfully for char, int, > NBExternalAddress etc. But Iâm trying to get it working for strings. So > here is the code that I would expect to work: > > arrayClass := NBExternalArray anonymousSubclassInitElementType: 'String'. > array := arrayClass new: 1. > array at: 1 put: âfoo'. > array at: 1. ââ> should procude âfooâ, but produces arbitrary stringsâ > interesting > > I can make it work with NBExternalAddress of course but I donât want to if > I can avoid it. > How would you use NBExternalAddress in this case? > > Iâd appreciate it if someone (Nicolai?) could take a look at > NBExternalArray>>emitRead / emitWrite and see if thereâs an easy solution. > Especially for strings I donât think it should be too hard since all thatâs > needed is already present in the string handling facilities. > Somehow it only works half the way, either write the String / or read the String. this one: arrayClass := NBExternalArray ofType: 'String'. array := arrayClass new: 1. array at: 1 put: 'foo'. array at:1 reads the data back to a string object, but I think the data was written wrong. this one: arrayClass := NBExternalArray ofType: 'char*'. array := arrayClass new: 1. array at: 1 put: 'foo'. at least writes the right data, but now array at:1 contains an external address and it is not automatically converted back to a string. You can confirm that the data is written correctly by explicitly creating a string from the external address. (array at:1) readString -> 'foo' Now, why is the String data written wrong in the first case? (Maybe this has something to do with #pointerArity. I think NBExternalString should have pointerArity 1. I changed this for NBExternalString, but it seems this does not make a difference - and may break other things). It looks like some "double conversion" ST-String -> char*, that is, it converts a String as NBExternalString and uses this to do the conversion again: I played it bit with the code (NB makes really fun, no irony, it really makes fun, it is a nice piece of work). and created a new NBExternalArray subclass StringArray: NBExternalArray subclass: #StringArray instanceVariableNames: '' classVariableNames: '' category: 'NativeBoost-Core-Objects' define the class initialize method initialize self initElementType: #String and overwrite emitWrite, the same code as in NBExternalArray, but replace function: ' oop ( oop value , uint32 index , void * data , ' , self class elementType , ' value )' with function: ' oop ( oop value , uint32 index , void * data , char* value )' now, this works: arrayClass := StringArray. array := arrayClass new: 1. array at: 1 put: 'foo'. (array at:1) -> 'foo' So, maybe the default function prototype in NBExternalArray>>#emitWrite is responsible for the double conversion or the pointer arity. I don't fully understand what is going on :), but maybe this helps. nicolai > > Cheers, > Max >

April 27, 2015

[pharo-project/pharo-core]

by GitHub

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

April 27, 2015