- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Are these changes good enough

by Sergio Fedi

One thing I previously missed: marking it as resolved (and in need for a peer review) Already done that at: https://pharo.fogbugz.com/f/cases/resolve/15417/TestRunner-does-not-offer-t… â

April 27, 2015

Re: [Pharo-dev] Are these changes good enough

by Sergio Fedi

Great, it seems I've managed to upload the fix. *The issue number* is 15417 *This is the result of the commit* Name: SUnit-UI-SergioFedi.111 Author: SergioFedi Time: 27 April 2015, 7:16:53.814736 pm UUID: cbc836f0-a6bf-4847-a3be-da8b2b67657a Ancestors: SUnit-UI-TheIntegrator.110 Added runCovergae button and it's corresponding functionality. Note: unlike what it says in the video, I didn't ask for rights to submit, I simply made and account and submitted the change. Is there anything else I should do? Also, feel free to point me to any kind of mistake or breach in protocol I've made.

April 27, 2015

Re: [Pharo-dev] Tx Pass

by Nicolai Hess

2015-04-27 22:41 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Finally "passed" validation (minus two random failures): > great! > > > DelayMillisecondSchedulerTest>>#testTestInterferenceWithSystemTimingSemaphore > SetTest>>#testAllSetsAreHealthy > I manually loaded the config in 50012 and these both passed. > > Marked "Fix to Include" > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Tx-Pass-tp4822173p4822270.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 27, 2015

Re: [Pharo-dev] Tx Pass

by Sean P. DeNigris

Finally "passed" validation (minus two random failures): DelayMillisecondSchedulerTest>>#testTestInterferenceWithSystemTimingSemaphore SetTest>>#testAllSetsAreHealthy I manually loaded the config in 50012 and these both passed. Marked "Fix to Include" ----- Cheers, Sean -- View this message in context: http://forum.world.st/Tx-Pass-tp4822173p4822270.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 27, 2015

Re: [Pharo-dev] Integration process in presence of "external" project

by Esteban Lorenzano

> On 27 Apr 2015, at 22:19, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > I will soon release a âversioner commit toolâ who will help with this. > The process will remain as now: > > you do your changes > you do âcommit version of Xâ (where X can be from âRubricâ to âGTSpotterâ (and in the hopefully not far future even âNautilusâ or, why not âPharo-IDEâ or even âPharoâ) > tools will collect packages and configurations and generate new ones, using semver nomenclature. > finally, you will copy your âmainâ configuration (the root of your change) to the inbox (same as now). > > this is the beginning of the end of SLICEd based development. > and this is the beginning of a modular era :) > > This is almost ready and is a good example of incremental changes that produces a fundamental lap (remember ânomads do not build cathedralsâ talk from Marcus): > > - gofer allows the scripting of commit and load packages > - metacello allows us to declare and manage dependences > - versionner does a very good job maintaining metacello configurations > - version commit tool will allow the automation release pacthes for nested configurations ah, and I forget to mention the other part: - we have minimal images (6m)â¦ and in the future even a bootstrapped minimal image. - we have the capability of ârebuildâ a complete Pharo from a Pharo-minimal image (Pavel just send me this cool link: https://ci.inria.fr/pharo/view/5.0-SysConf/job/Pharo-5.0-ConfigurationOfIDE <https://ci.inria.fr/pharo/view/5.0-SysConf/job/Pharo-5.0-ConfigurationOfIDE>) So the progress is in good shape in both directions :) > > Esteban > > ps: and when I said almost ready, it is for real: I hope to release an alpha version for testing tomorrow :) > pps: sounds bad to put this last tool in the list to the big contributionsâ¦ at the end, is just a small tool on top of really important projects :)) > >> On 27 Apr 2015, at 21:39, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> stepharo wrote >>> - we do a fix we publish it in Pharo and yes this touches Rubric and >>> - we integrate it in Pharo head >> >> I'm not clear what the best process is, but I wanted to relate an experience >> I just had updating TxText... >> Tool-TxWorkspace-TheIntegrator.6 is the version in Pharo 5.0. Its ancestor, >> which I wanted to copy to the TxText repo, is >> Tool-TxWorkspace-TorstenBergmann.5. I couldn't find it anywhere. I checked >> the Pharo40, Pharo50, and Pharo/TxText repos; and then started checking >> others e.g. sig/TxText. Eventually I found it in the Pharo40Inbox, copied it >> over, and updated the config. >> >> So, for external projects, simply taking changes from the inbox and >> integrating seems to be a little lacking. Maybe at least copy the packages >> back to the canonical repos to preserve the ancestry... >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Integration-process-in-presence-of-external-project-t… >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >

April 27, 2015

Re: [Pharo-dev] Integration process in presence of "external" project

by Esteban Lorenzano

I will soon release a âversioner commit toolâ who will help with this. The process will remain as now: you do your changes you do âcommit version of Xâ (where X can be from âRubricâ to âGTSpotterâ (and in the hopefully not far future even âNautilusâ or, why not âPharo-IDEâ or even âPharoâ) tools will collect packages and configurations and generate new ones, using semver nomenclature. finally, you will copy your âmainâ configuration (the root of your change) to the inbox (same as now). this is the beginning of the end of SLICEd based development. and this is the beginning of a modular era :) This is almost ready and is a good example of incremental changes that produces a fundamental lap (remember ânomads do not build cathedralsâ talk from Marcus): - gofer allows the scripting of commit and load packages - metacello allows us to declare and manage dependences - versionner does a very good job maintaining metacello configurations - version commit tool will allow the automation release pacthes for nested configurations Esteban ps: and when I said almost ready, it is for real: I hope to release an alpha version for testing tomorrow :) pps: sounds bad to put this last tool in the list to the big contributionsâ¦ at the end, is just a small tool on top of really important projects :)) > On 27 Apr 2015, at 21:39, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > stepharo wrote >> - we do a fix we publish it in Pharo and yes this touches Rubric and >> - we integrate it in Pharo head > > I'm not clear what the best process is, but I wanted to relate an experience > I just had updating TxText... > Tool-TxWorkspace-TheIntegrator.6 is the version in Pharo 5.0. Its ancestor, > which I wanted to copy to the TxText repo, is > Tool-TxWorkspace-TorstenBergmann.5. I couldn't find it anywhere. I checked > the Pharo40, Pharo50, and Pharo/TxText repos; and then started checking > others e.g. sig/TxText. Eventually I found it in the Pharo40Inbox, copied it > over, and updated the config. > > So, for external projects, simply taking changes from the inbox and > integrating seems to be a little lacking. Maybe at least copy the packages > back to the canonical repos to preserve the ancestry... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Integration-process-in-presence-of-external-project-t… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

April 27, 2015

Re: [Pharo-dev] Integration process in presence of "external" project

by Sean P. DeNigris

stepharo wrote > - we do a fix we publish it in Pharo and yes this touches Rubric and > - we integrate it in Pharo head I'm not clear what the best process is, but I wanted to relate an experience I just had updating TxText... Tool-TxWorkspace-TheIntegrator.6 is the version in Pharo 5.0. Its ancestor, which I wanted to copy to the TxText repo, is Tool-TxWorkspace-TorstenBergmann.5. I couldn't find it anywhere. I checked the Pharo40, Pharo50, and Pharo/TxText repos; and then started checking others e.g. sig/TxText. Eventually I found it in the Pharo40Inbox, copied it over, and updated the config. So, for external projects, simply taking changes from the inbox and integrating seems to be a little lacking. Maybe at least copy the packages back to the canonical repos to preserve the ancestry... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Integration-process-in-presence-of-external-project-t… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 27, 2015

Re: [Pharo-dev] Tx Pass

by Esteban Lorenzano

yes! thanks :) > On 27 Apr 2015, at 20:55, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sean P. DeNigris wrote >> >> Sean P. DeNigris wrote >>> Issue 15414: TxText Cleanup for Pharo 5.0 #1 >>> https://pharo.fogbugz.com/default.asp?15414 >> It would be great to get this into the image ASAP so I can keep working on >> it :) > > I fixed the validation errors. The two left seem unrelated. > https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/667//artifact/valid… > > Are we okay to include? > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Tx-Pass-tp4822173p4822238.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 Max Leske

> On 27 Apr 2015, at 16:14, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > >> 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. Right. So space is allocated for the constant sized objects or the pointers but not for the variable sized objectsâ¦ That explains what Iâm seeing with the memory being used sometimes. I guess allocation and finalization can easily be done in a dedicated subclass, so Iâll try that. Thanks a lot Henry! Cheers, Max > > 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

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

by Max Leske

> On 27 Apr 2015, at 10:42, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Hi Max > > 2015-04-26 19:29 GMT+02:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@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? By using 'char *â or 'NBExternalAddress' as type and then converting back to a String by sending #readString to the address. My current solution acutally does that but it seems that the allocated memory is being freed sometimes without my doing, so Iâm trying to let NBExternalAddress do as much as possible for me. > > > 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. exactlyâ¦ > > > 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 )â Smart! If that works conistently (Iâll test it) we should be able to find the problem. > > 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. Thanks a lot Nicolai, I really appreciate your help. Cheers, Max > > nicolai > > > > > Cheers, > Max >

April 27, 2015