- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #1353: REVERT-22239-DataAndTimeTesttestAsDateAndTime-is-meaningful

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1353 was: FAILURE. The Pull Request #1945 was integrated: "REVERT-22239-DataAndTimeTesttestAsDateAndTime-is-meaningful" Pull request url: https://github.com/pharo-project/pharo/pull/1945 Issue Url: https://pharo.fogbugz.com/f/cases/REVERT Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 30, 2018

[Pharo 7.0-dev] Build #1352: 21667-Dropping-a-mcz-on-image-raises-an-error

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1352 was: FAILURE. The Pull Request #1939 was integrated: "21667-Dropping-a-mcz-on-image-raises-an-error" Pull request url: https://github.com/pharo-project/pharo/pull/1939 Issue Url: https://pharo.fogbugz.com/f/cases/21667 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 30, 2018

[Pharo 7.0-dev] Build #1351: 22615-Random-Core-can-be-removed-form-the-manual-dependencies-list-of-Collections-String

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1351 was: FAILURE. The Pull Request #1944 was integrated: "22615-Random-Core-can-be-removed-form-the-manual-dependencies-list-of-Collections-String" Pull request url: https://github.com/pharo-project/pharo/pull/1944 Issue Url: https://pharo.fogbugz.com/f/cases/22615 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 29, 2018

[Pharo 7.0-dev] Build #1350: 22499-modifying-a-method-in-a-trait-that-is-aliased-in-a-class-is-not-propagated-correctly-

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1350 was: FAILURE. The Pull Request #1938 was integrated: "22499-modifying-a-method-in-a-trait-that-is-aliased-in-a-class-is-not-propagated-correctly-" Pull request url: https://github.com/pharo-project/pharo/pull/1938 Issue Url: https://pharo.fogbugz.com/f/cases/22499 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 29, 2018

Re: [Pharo-dev] Streams and FileDialog in Pharo 6 and 7

by Guillermo Polito

Well, there are still variants - chooseFile* - fileOpen* - fileSave* - chooseFileName* - chooseFullFileName* I prefered rather to be explicit and to avoid confusion with the old API (which I deprecated, not removed!) On Sat, Oct 27, 2018 at 2:42 PM Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > What about different names? > > UIManager default > chooseFileIn: aFileReference > withExtensions: #() > title: 'title' > > UIManager default > chooseFileForSaveIn: aFileReference > withExtensions: #() > title: 'title' > > We can just expect file references because it is what is exposed to users > in pharo file system. Not neccessery to put it in method name. > > Ð¿Ñ, 26 Ð¾ÐºÑ. 2018 Ð³., 16:32 Guillermo Polito <guillermopolito(a)gmail.com>: > >> Hi all, >> >> I've proposed a PR with some cleanups in this respect >> >> https://github.com/pharo-project/pharo/pull/1941 >> >> This is the proposed replacement API that returns file references instead >> of streams or file names. >> >> "Get existing file reference" >> UIManager default >> chooseExistingFileReference: 'title' >> extensions: nil >> path: FileSystem workingDirectory. >> >> "Get existing file reference filtering by extensions" >> UIManager default >> chooseExistingFileReference: 'title' >> extensions: #('log') >> path: FileSystem workingDirectory. >> >> "Get existing file reference to file" >> UIManager default >> chooseExistingFileReference: 'title' >> extensions: nil >> path: FileSystem workingDirectory / 'PharoDebug.log'. >> >> "Get file reference for save (not necessarily existing)" >> UIManager default >> chooseForSaveFileReference: 'title' >> extensions: #('log') >> path: 'PharoDebuasdg.log'. >> >> On Fri, Oct 26, 2018 at 3:11 PM Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Ok, so can we agree on deprecating the non compatible methods and >>> redirect the user to the new ones? >>> >>> To me, the problem with returning a stream is that from a user >>> perspective you don't know: >>> - is the file encoded or binary >>> - if it is encoded, in which encoding? >>> - if i receive an open file stream, and I want to delete that file I >>> have to close it, retrieve the file, delete it? >>> - IMHO, what is the worst: whose responsibility is it to close the file? >>> >>> On Thu, Sep 6, 2018 at 10:43 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>> >>>> > It should return a FileReference, not an open stream. I believe >>>> there are methods that do that. >>>> >>>> There are different APIs for that. >>>> >>>> fileOpen*, as the name implies, _opens the file_ and returns the >>>> stream. (I think this should be the case for fileSave*) >>>> >>>> If you want file reference, then you can use e.g. >>>> >>>> UIManager default chooseFileMatching: #() label: nil >>>> >>>> or `chooseFileMatching:label:`, >>>> `chooseFileName:extensions:path:preview:`, >>>> `chooseFullFileName:extensions:path:preview:`, >>>> `chooseFullFileNameMatching:label:`. >>>> Also some methods for selecting directories >>>> (`chooseDirectory:path:`, chooseDirectory:from:`, ...) >>>> >>>> iirc some of them actually return String (file path) instead of >>>> FileReference. ( >>>> https://gist.github.com/peteruhnak/8ac6667b8eb11daee71517d0172b7355#file-ui… >>>> ) >>>> >>>> So it can be confusing, but the API is already available. >>>> >>>> Also iirc UIManager should be preferred over UITheme builder. >>>> >>>> Peter >>>> >>>> On Thu, Sep 6, 2018 at 9:57 PM Sven Van Caekenberghe <sven(a)stfx.eu> >>>> wrote: >>>> >>>>> >>>>> >>>>> > On 6 Sep 2018, at 21:37, Torsten Bergmann <astares(a)gmx.de> wrote: >>>>> > >>>>> > Hi, >>>>> > >>>>> > A question to those who worked on the new streams for Pharo 7: >>>>> > >>>>> > >>>>> > In PHARO 6 I used the following expression to open a file dialog and >>>>> let the user choose >>>>> > a binary file: >>>>> > >>>>> > s := UITheme builder fileOpen: 'Choose a file' extensions: >>>>> #('exe'). >>>>> > >>>>> > This returned >>>>> > - either nil (when file dialog was canceled) >>>>> > - a "MultiByteFileStream" instance when a file was selected >>>>> > >>>>> > The MultiByteFileStream instance already had the name of the file (= >>>>> full path) and I was >>>>> > able to query it for further use: >>>>> > >>>>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >>>>> > s name inspect >>>>> > >>>>> > (for instance to display which file is processed in a window by >>>>> showing the full path) >>>>> > >>>>> > >>>>> > >>>>> > Now in PHARO 7 same expression returns an instance of >>>>> ZnCharacterReadStream (as MultiByteFileStream >>>>> > is deprecated): >>>>> > >>>>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >>>>> > >>>>> > and ZnCharacterReadStream does not understand #name - and in fact >>>>> the info about the name is >>>>> > totally lost/not available. To me this looks missing/broken. >>>>> > >>>>> > So what is the recommended way in Pharo 7 to open a file dialog, let >>>>> the use choose a file >>>>> > and get a file stream but also the name? IMHO this is either broken >>>>> or missing... >>>>> > >>>>> > Thanks >>>>> > T. >>>>> >>>>> It should return a FileReference, not an open stream. I believe there >>>>> are methods that do that. >>>>> >>>>> But that is an incompatible API change (same selector, different >>>>> return type). So hard to decide. >>>>> >>>>> >>>>> >>> >>> -- >>> >>> >>> >>> Guille Polito >>> >>> Research Engineer >>> >>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>> >>> CRIStAL - UMR 9189 >>> >>> French National Center for Scientific Research - *http://www.cnrs.fr >>> <http://www.cnrs.fr>* >>> >>> >>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>> >>> *Phone: *+33 06 52 70 66 13 >>> >> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 >> > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Oct. 29, 2018

Esteban's ChangeLog week of 22 October 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 22 October 2018 to 28 October 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=22/10/2018&to=28/10/2018 ChangeLog ========= 22 October 2018: ---------------- * I (finally) finnished couple of PRs for Calypso! * [Issue 304](https://github.com/pharo-ide/Calypso/pull/346) * [Issue 335](https://github.com/pharo-ide/Calypso/pull/348) This two are the content of my work of last week. It was complicated to understand the model behind calypso and that took more time than preview. A bit of an explanation: 1. First one eliminates the extension that takes +Traits+ as if they would be superclasses of somekind. While I understand what Denis tried to do here, the premise he took is wrong: traits are not a multiple inheritance mechanism (even if they can be used to simulate it), traits are a *composition* strategy (and there is a trait composition arithmetic that is somekind complex that needs to be taken into account). As a result, the price of simulating a multiple-inheritance scenario where there is not was complexifying the model at levels way higher than desired. Also it was not working properly and patching it to make it work was resulting on re-writing all the trait arithmetic at UI level. So the right approach here is just to remove. And to be clear: I'm not oposed to the existence of a plugin that hides methods comming from traits (even if I think is incorrect because once a trait is applied, those methods actually 'belong' to the class). But in case you want something like this, it can be implemented in a much simpler way by not mixing what a superclass and a trait is. 2. Second PR also eliminates something :) This time I eliminate the inclusion of metaclasses in the extension list while displaying a package. Again, I understand what Denis tried to do: to easy the view of which classes are extended in the class side and the ones that are extended in instance side. Problem with thid is that it was breaking completely the cognitive model the system browser offers, which is already complex enough to add also an exceptional behaviour. Anyway, this list now works as before: if there are extensions classes are shown and to see the class side extensions you need to click in class side option. cheers! Esteban

Oct. 29, 2018

Re: [Pharo-dev] Xcode projects for VM on iOS or Mac?

by John M McIntosh

Although xCode makes much of that process easier it is just a GUI front end for a bunch of command line tools. You can re-sign and submit an app from the command line for enterprise usage, no doubt the same for the store. Apple at one time had a utility app to submit apps to the store for people needed to sub 100âs of apps at a time. .... John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk On Sun, Oct 28, 2018 at 21:04, Todd Blanchard via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > I'm more about wanting an iOS VM and to do that you need to build and sign through Apple's tool set as far as I know. > > And the debugging experience is much more pleasant - especially when making FFI calls into Apple's system libraries. > > CMake can build an Xcode project from a CMake build system I believe. At least there is a cross platform marine navigation project called OpenCPN (written in C++ and which relies on wxWidgets) that does this. > > So I'm not arguing to have the official builds in Xcode, but if you want to build an app and ship it on iPhone or Mac, Xcode is the build system you are going to need to submit it to the App store. > >> On Oct 28, 2018, at 12:27 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Todd, >> >> On Fri, Oct 26, 2018 at 10:00 AM Todd Blanchard via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: >> >>> Does anyone have Xcode projects for building the VM on iOS or Mac? Can they share them or give me some tips for setting one up? >> >> First I'd like to know your use case. I presume it;'s for debugging, but it may be more for browsing. Can you say? (Personally I find raw lldb adequate for debugging). >> >> Second, my reasons for not using Xcode projects for building the Mac VMs are that >> - Xcode projects, being a serialization of an object graph, are difficult to edit, and they offer no parameterisation, so whereas there is one small set of makefiles (8 in all) for all of the 32-bit and 64-bit builds on Mac, there had to be a separate Xcode project for each build. When adding Spur this was simply unsupportable >> - clearly Xcode is not necessary for building, browsing, or debugging; people are able to accomplish all three tasks using other tools >> >> However, I do appreciate that Xcode is a more pleasant and higher-level GUI interface than the shell, make, lldb and one's favorite editor. What I would support is a tool that created an Xcode project from Makefiles; such tools used to exist. I'd love to see such a tool. What I will fight against until my dying breath is any attempt to replace the Makefile based build system with Xcode. I hope the reasons above justify why. >> >> _,,,^..^,,,_ >> best, Eliot

Oct. 29, 2018

Re: [Pharo-dev] Xcode projects for VM on iOS or Mac?

by Todd Blanchard

I'm more about wanting an iOS VM and to do that you need to build and sign through Apple's tool set as far as I know. And the debugging experience is much more pleasant - especially when making FFI calls into Apple's system libraries. CMake can build an Xcode project from a CMake build system I believe. At least there is a cross platform marine navigation project called OpenCPN (written in C++ and which relies on wxWidgets) that does this. So I'm not arguing to have the official builds in Xcode, but if you want to build an app and ship it on iPhone or Mac, Xcode is the build system you are going to need to submit it to the App store. > On Oct 28, 2018, at 12:27 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Todd, > > On Fri, Oct 26, 2018 at 10:00 AM Todd Blanchard via Pharo-dev <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> wrote: > Does anyone have Xcode projects for building the VM on iOS or Mac? Can they share them or give me some tips for setting one up? > > First I'd like to know your use case. I presume it;'s for debugging, but it may be more for browsing. Can you say? (Personally I find raw lldb adequate for debugging). > > Second, my reasons for not using Xcode projects for building the Mac VMs are that > - Xcode projects, being a serialization of an object graph, are difficult to edit, and they offer no parameterisation, so whereas there is one small set of makefiles (8 in all) for all of the 32-bit and 64-bit builds on Mac, there had to be a separate Xcode project for each build. When adding Spur this was simply unsupportable > - clearly Xcode is not necessary for building, browsing, or debugging; people are able to accomplish all three tasks using other tools > > However, I do appreciate that Xcode is a more pleasant and higher-level GUI interface than the shell, make, lldb and one's favorite editor. What I would support is a tool that created an Xcode project from Makefiles; such tools used to exist. I'd love to see such a tool. What I will fight against until my dying breath is any attempt to replace the Makefile based build system with Xcode. I hope the reasons above justify why. > > _,,,^..^,,,_ > best, Eliot

Oct. 29, 2018

Re: [Pharo-dev] Xcode projects for VM on iOS or Mac?

by Eliot Miranda

Hi Todd, On Fri, Oct 26, 2018 at 10:00 AM Todd Blanchard via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > Does anyone have Xcode projects for building the VM on iOS or Mac? Can > they share them or give me some tips for setting one up? > First I'd like to know your use case. I presume it;'s for debugging, but it may be more for browsing. Can you say? (Personally I find raw lldb adequate for debugging). Second, my reasons for not using Xcode projects for building the Mac VMs are that - Xcode projects, being a serialization of an object graph, are difficult to edit, and they offer no parameterisation, so whereas there is one small set of makefiles (8 in all) for all of the 32-bit and 64-bit builds on Mac, there had to be a separate Xcode project for each build. When adding Spur this was simply unsupportable - clearly Xcode is not necessary for building, browsing, or debugging; people are able to accomplish all three tasks using other tools However, I do appreciate that Xcode is a more pleasant and higher-level GUI interface than the shell, make, lldb and one's favorite editor. What I would support is a tool that created an Xcode project from Makefiles; such tools used to exist. I'd love to see such a tool. What I will fight against until my dying breath is any attempt to replace the Makefile based build system with Xcode. I hope the reasons above justify why. _,,,^..^,,,_ best, Eliot

Oct. 28, 2018

Re: [Pharo-dev] [squeak-dev] Open Croquet will ahve issues in next version of Mac OS X

by Nikolay Suslov

Hello Lawson, Thanks for raising that question about 64 bit future of Open Croquet and Mac OS X support. I have tested the possibility of running Open Croquet on recent 64 bit version of Squeak 5.2. And it seems to be working, on Windows at least. Due to the B3DAccelerator and Croquet plugins, which are available in recent Squeak 64 bit VMs (there are still some issues with B3DAccelerator plugin on macOS). Here is preloaded image for Squeak: https://www.krestianstvo.org/sdk/croquet/Squeak5.2-18225-64bit-Croquet-Imag… Yes, you are right, that replication from participant running Croquet 64 bit image onto participant with 32 bit image or vice versa will not work properly by default. What is about supporting of 3D graphics in future versions of macOS, may be the time is coming to think about Metal FFI bindings. And yes, potentially this integration should work on Pharo too. Best regards, Nikolai On Mon, Oct 22, 2018 at 11:24 PM LawsonEnglish <LEnglish5(a)cox.net> wrote: > https://blog.krestianstvo.org/en/open-croquet-for-squeak-6/ > > > This sounds really cool, but thereâs an issue coming up: > > Apple is doing away with ANY support for 32-bit apps and plugins and of > course, Croquet is built for 32-bits and uses 32-bit plugins all over the > place. > > > > Croquet could STILL be the killer-app for Smalltalk even though it never > realized its potential in the past, and it wonât be able to if something > isnât done about the looming 32-bit vs 64-bit issue. > > Need I point out that it should work on Pharo just the same way it does on > Squeak? > > L > >

Oct. 28, 2018