- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] stdev

by stepharo

No this is my initials. I should have copyrighted them so may be we could have decent names. Le 28/9/16 Ã 21:26, phil(a)highoctane.be a Ã©crit : > In R, it is even shorter: > > https://stat.ethz.ch/R-manual/R-devel/library/stats/html/sd.html > > > On Wed, Sep 28, 2016 at 7:50 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi guys > > > is stdev a typical name for standardDeviation? > > Because I found it sad to have mean and stdev instead of mean and > standardDeviation. > > > Stef > > >

Sept. 28, 2016

Re: [Pharo-dev] stdev

by phil＠highoctane.be

In R, it is even shorter: https://stat.ethz.ch/R-manual/R-devel/library/stats/html/sd.html On Wed, Sep 28, 2016 at 7:50 PM, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > > is stdev a typical name for standardDeviation? > > Because I found it sad to have mean and stdev instead of mean and > standardDeviation. > > > Stef > > >

Sept. 28, 2016

stdev

by stepharo

Hi guys is stdev a typical name for standardDeviation? Because I found it sad to have mean and stdev instead of mean and standardDeviation. Stef

Sept. 28, 2016

Re: [Pharo-dev] [Pharo-users] Tech Meeting notes

by Peter UhnÃ¡k

Thanks for the recording, I wasn't able to attend so it's good to at least hear about the current state of things. Peter On Tue, Sep 27, 2016 at 7:37 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > And for those that were not able to attend the voice meeting here you can > find the recording so you can listen to it at your convenience > > https://dl.dropboxusercontent.com/u/1404140/Pharo%20Voice% > 20Meetings/PharoVR1.ogg > > Have fun :) > > On Tue, Sep 27, 2016 at 8:23 PM stepharo <stepharo(a)free.fr> wrote: > >> Hi guys >> >> I tried to take some notes of the discussion and report of effort made >> by esteban >> >> >> >> >> VM works >> ======== >> - migrating our source to opensmalltalk vm 80% of our source >> - keybindings enhancement >> - shift key pressed >> - library symbols >> - change our cmake maker -> plain makefiles >> - port our process (running all the tests) >> - new VMs will get out >> - ARM VM is under dev and started to run. >> - migration planned for end of week of next weeks >> >> - right now able to build >> 32 and 64 on mac and linux. >> plan with mid october. >> >> - for windows >> - We will produce assert vm to help people to find problems. >> >> - Sierra support is coming. >> - openssl >> It will come after the end of the merge finished. >> >> - FFI bug about the Athens canvas. >> >> - FT bug is getting on the radar and esteban suspects that the bug >> is in the C plugin. We plan to throw away the FT plugin. >> If people want to help please have a look at thibaultRaffaillac >> bindings. >> >> - Pharo is using different VM functionalities so sometimes we are >> going >> on unfrequented paths. >> >> - Threaded FFI will come after 64, ARM, two bugs >> Probably beginning of the year. >> >> >> Iceberg >> ======== >> here is the log that nicolas sent to our internal mailing-list >> >> ### Last week: >> - Improved travis support, working on having all green tests in travis, >> still 4 to go. >> - Extending libgit support. >> - Support for synchronizing an Iceberg repository with code that was >> loaded with gitfiletree (was not working, as reported by Norbert). >> - Fixed some bugs (see >> https://github.com/npasserini/iceberg/milestone/7?closed=1) >> >> >> ### This week (starting 2016-09-26): >> >> - Finish having all tests running on travis. >> - Better management of ssh keys (which in turn is required for travis >> working correctly). >> - Also I would like to add some little GUI details that bother me in >> daily work (such as remembering common options, highlighting outdated >> repositories, or opening repositories from spotter). >> >> I think that this might take the whole week. After that I plan to add >> basic support synchronizing against code that was loaded from any >> repository. With that finished, we could release v0.3 >> >> After that, the plan for v0.4 is to make libgit our default backend, and >> make gitfiletree dependencies optional. >> - I am pretty close to have all tests running for libgit again, then we >> should try to use libgit as backend for the UI. But in that process also >> improve test coverage so that we minimize dependence on manual >> verification of the UI. >> - Remodularice in order to separate gitfiletree dependencies, so we will >> be able to use Iceberg without loading ossubprocess (or gitfiletree). >> - That will require also to write an independent cypress reader/writer, >> because the current one inherits from gitfiletree. >> >> If we have all this, I think that we could have a version that could be >> included in the base image, probably in the second half of october. >> >> >>

Sept. 28, 2016

[pharo-project/pharo-core]

by GitHub

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

Sept. 28, 2016

[pharo-project/pharo-core] 90435d: 60242

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 90435d4523791cb41cd1f4926638bdae4dc8eed2 https://github.com/pharo-project/pharo-core/commit/90435d4523791cb41cd1f492… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-09-28 (Wed, 28 Sep 2016) Changed paths: M AST-Core.package/NumberParser.class/instance/parsing-private/readExponent.st A AST-Tests-Core.package/NumberParserTest.class/instance/tests - Float/testFloatMaxAndMin.st M Kernel.package/Deprecation.class/definition.st A Kernel.package/Deprecation.class/instance/accessing/contextOfDeprecatedMethod.st A Kernel.package/Deprecation.class/instance/accessing/contextOfSender.st A Kernel.package/Deprecation.class/instance/accessing/context_.st M Kernel.package/Deprecation.class/instance/accessing/messageText.st R Kernel.package/Deprecation.class/instance/accessing/methodReference.st R Kernel.package/Deprecation.class/instance/accessing/method_.st R Kernel.package/Deprecation.class/instance/accessing/sendingMethodName.st R Kernel.package/Deprecation.class/instance/accessing/sendingMethodName_.st M Kernel.package/Deprecation.class/instance/comparing/=.st M Kernel.package/Deprecation.class/instance/comparing/hash.st M Kernel.package/Deprecation.class/instance/handling/transform.st A Kernel.package/Deprecation.class/instance/private/deprecatedMethodName.st A Kernel.package/Deprecation.class/instance/private/sendingMethodName.st M Kernel.package/Object.class/instance/deprecation/deprecated_.st M Kernel.package/Object.class/instance/deprecation/deprecated_on_in_.st M Kernel.package/Object.class/instance/deprecation/deprecated_on_in_transformWith_.st M Kernel.package/Object.class/instance/deprecation/deprecated_transformWith_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60241.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60242.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60241.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60242.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M UnifiedFFI-Tests.package/FFICallbackTests.class/definition.st A UnifiedFFI-Tests.package/FFICallbackTests.class/instance/support/wordResult_.st A UnifiedFFI-Tests.package/FFICallbackTests.class/instance/tests/testEnumerationReturnValue.st A UnifiedFFI.package/FFIExternalEnumerationType.class/instance/accessing/callbackReturnOn_for_.st Log Message: ----------- 60242 19145 FFI Callback return values for Enumerations should return their integer value https://pharo.fogbugz.com/f/cases/19145 19144 (FloatTest >> #testBinaryLiteralString) method cannot be compiled in latest image https://pharo.fogbugz.com/f/cases/19144 19132 simplify Deprecation class https://pharo.fogbugz.com/f/cases/19132 http://files.pharo.org/image/60/60242.zip

Sept. 28, 2016

Re: [Pharo-dev] UFFI #isPointer - absolute or versus naturalPointerArity

by Eliot Miranda

Hi Ben, On Tue, Sep 27, 2016 at 8:40 AM, Ben Coman <btc(a)openinworld.com> wrote: > First, my C is a bit rusty so a question about semantics... > > int * a; > typedef int * MyInt; > MyInt b; > > So obviously the type of 'a' is a pointer, > but is the type of 'b' a pointer? > My intuition is that its not, since the pointer is wrapped inside the type. > Yes it is. MyInt (a bad name) is a type that is a pointer to an int. So something of type MyInt is of type pointer to int. > Now in my UFFI tutorial > http://blog.openinworld.com/2016/09/pharo-libclang-ffi- > part-4-ast-walking-with-visitors-callbacks/ > I have a callback that I've modified here adding the #inspect... > > acceptCallbackFn := > FFICallback > signature: #( CXChildVisitResult ( > CXCursor cursor, > CXCursor parent, > CXClientData client_data)) > block: [ :cursor :parent :clientData | > client_data inspect. > visitResult add: cursor kind item. > aCXChildVisitResult value "@1" ]. > > This can be invoked by running #testVisitChildrenCallbackBreak > and an inspector opens on an ExternalAddress instead of > the expected CXClientData. > > FFIExternalObject subclass: #CXClientData > instanceVariableNames: '' > classVariableNames: '' > package: 'Libclang' > > where the FFIExternalObject says... > "A typical usage of me is to create a subclass, and then use that > subclass name directly in function signatures ... By putting > FFIExternalObject subclass ... as a return type into the function > signature, we are telling the code generator to ***automatically*** > convert the return value into an instance of a given class and > initialize its handle to the value returned by the function." > > > This decision to return ExternalAddress instead of CXClientData > occurs here... > FFIExternalObjectType(FFIExternalType)>>handle: aHandle at: index > self isPointer ifTrue: [ ^ aHandle pointerAt: index ]. > ^ self basicHandle: aHandle at: index > > since... > FFIExternalType>>isPointer > ^ self pointerArity > 0 > > and... > FFIExternalObjectType(FFIExternalReferenceType)>>naturalPointerArity > ^ 1 > > So this naturalPointerArity=1 represents the situation presented with > the C code at the top. So should #isPointer consider only the > absolute pointerArity, or should is be... > > FFIExternalType>>isPointer > ^ self pointerArity > self class naturalPointerArity > > Indeed, if I do that, plus these two additions copied from > FFIExternalStructure... > > FFIExternalReferenceType>>basicHandle: aHandle at: index > ^ self objectClass fromHandle: aHandle. > > FFIExternalReference>>fromHandle: aHandle > ^self basicNew setHandle: aHandle > > Now running #testVisitChildrenCallbackBreak > opens an inspector opens on a CXClientData as expected. > And all UFFI tests continue to run fine. > > > One thing I found strange though was... > FFIExternalStructureType>>naturalPointerArity > ^ 1 > > I would have thought a struct's natural pointer arity was 0 ? > > wdyt? > cheers -ben > This makes my brain hurt. A pointer is a pointer, whether it points to a pointer or a datum. Hence I find the "self pointerArity > self class naturalPointerArity" approach confusing. _,,,^..^,,,_ best, Eliot

Sept. 28, 2016

Re: [Pharo-dev] [Pharo-users] Tech Meeting notes

by Dimitris Chloupis

And for those that were not able to attend the voice meeting here you can find the recording so you can listen to it at your convenience https://dl.dropboxusercontent.com/u/1404140/Pharo%20Voice%20Meetings/PharoV… Have fun :) On Tue, Sep 27, 2016 at 8:23 PM stepharo <stepharo(a)free.fr> wrote: > Hi guys > > I tried to take some notes of the discussion and report of effort made > by esteban > > > > > VM works > ======== > - migrating our source to opensmalltalk vm 80% of our source > - keybindings enhancement > - shift key pressed > - library symbols > - change our cmake maker -> plain makefiles > - port our process (running all the tests) > - new VMs will get out > - ARM VM is under dev and started to run. > - migration planned for end of week of next weeks > > - right now able to build > 32 and 64 on mac and linux. > plan with mid october. > > - for windows > - We will produce assert vm to help people to find problems. > > - Sierra support is coming. > - openssl > It will come after the end of the merge finished. > > - FFI bug about the Athens canvas. > > - FT bug is getting on the radar and esteban suspects that the bug > is in the C plugin. We plan to throw away the FT plugin. > If people want to help please have a look at thibaultRaffaillac > bindings. > > - Pharo is using different VM functionalities so sometimes we are > going > on unfrequented paths. > > - Threaded FFI will come after 64, ARM, two bugs > Probably beginning of the year. > > > Iceberg > ======== > here is the log that nicolas sent to our internal mailing-list > > ### Last week: > - Improved travis support, working on having all green tests in travis, > still 4 to go. > - Extending libgit support. > - Support for synchronizing an Iceberg repository with code that was > loaded with gitfiletree (was not working, as reported by Norbert). > - Fixed some bugs (see > https://github.com/npasserini/iceberg/milestone/7?closed=1) > > > ### This week (starting 2016-09-26): > > - Finish having all tests running on travis. > - Better management of ssh keys (which in turn is required for travis > working correctly). > - Also I would like to add some little GUI details that bother me in > daily work (such as remembering common options, highlighting outdated > repositories, or opening repositories from spotter). > > I think that this might take the whole week. After that I plan to add > basic support synchronizing against code that was loaded from any > repository. With that finished, we could release v0.3 > > After that, the plan for v0.4 is to make libgit our default backend, and > make gitfiletree dependencies optional. > - I am pretty close to have all tests running for libgit again, then we > should try to use libgit as backend for the UI. But in that process also > improve test coverage so that we minimize dependence on manual > verification of the UI. > - Remodularice in order to separate gitfiletree dependencies, so we will > be able to use Iceberg without loading ossubprocess (or gitfiletree). > - That will require also to write an independent cypress reader/writer, > because the current one inherits from gitfiletree. > > If we have all this, I think that we could have a version that could be > included in the base image, probably in the second half of october. > > >

Sept. 27, 2016

[pharo-project/pharo-core]

by GitHub

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

Sept. 27, 2016

[pharo-project/pharo-core] fe10c1: 60241

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: fe10c13f590e1d96570c78bbba7a0d0f6c23f25e https://github.com/pharo-project/pharo-core/commit/fe10c13f590e1d96570c78bb… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-09-27 (Tue, 27 Sep 2016) Changed paths: M Collections-Strings.package/String.class/instance/converting/substrings.st M Collections-Strings.package/String.class/instance/converting/substrings_.st M Collections-Tests.package/StringTest.class/instance/testing - converting/testSubstrings.st R Collections-Tests.package/TSortTest.class/instance/as yet unclassified/testSorted.st A Collections-Tests.package/TSortTest.class/instance/tests/testSorted.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60240.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60241.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60240.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60241.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/VersionBrowser.class/instance/instance creation/showSourceWithConverter_.st M Tool-Base.package/MethodClassifier.class/class/private/buildKeywordSuffixMapping.st M Tool-Base.package/MethodClassifier.class/class/private/buildPragmaMapping.st M Tool-Base.package/MethodClassifier.class/class/private/buildPrefixMapping.st A Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/setTextModelForTransformationRule_.st Log Message: ----------- 60241 19121 DNU in VersionBrowser when switching from "side by side" to "source" https://pharo.fogbugz.com/f/cases/19121 19143 in Code Critique browser: DNU #setTextModelForTransformationRule: https://pharo.fogbugz.com/f/cases/19143 18914 Improve MethodClassifier classification based on selector parts https://pharo.fogbugz.com/f/cases/18914 19141 Optimize String>>#substrings: https://pharo.fogbugz.com/f/cases/19141 http://files.pharo.org/image/60/60241.zip

Sept. 27, 2016