October 2018 - Pharo-dev - lists.pharo.org

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

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

by Denis Kudriashov

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 >

Oct. 27, 2018

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

by Esteban Lorenzano

Iâm sorry I forget to answer your mail :( Anyway, my response was not something you wanted to hear: I maintained the iOS version of the VM and up to three years ago (before spur) it was working, but I didnât try it since a lot of time and most of the work I did (who was based in CMakeMaker) is now not used anymore so I do not think they will work âout of the boxâ if needed. I find sad that we have to depend on otherâs Xcode projects to being able to do something, but wellâ¦ is better than nothing :) Esteban > On 26 Oct 2018, at 19:55, Todd Blanchard via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Todd Blanchard <tblanchard(a)mac.com> > Subject: Re: [Pharo-dev] Xcode projects for VM on iOS or Mac? > Date: 26 October 2018 at 19:55:24 CEST > To: John M McIntosh <johnmci(a)smalltalkconsulting.com>, Pharo Development List <pharo-dev(a)lists.pharo.org> > > > That would be super awesome! Please let me know if/when you do. > > Thanks, > -Todd Blanchard > >> On Oct 26, 2018, at 9:43 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com <mailto:johnmci@smalltalkconsulting.com>> wrote: >> >> I have one. I should see about adding it to a branch. >> >> .... >> John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk <https://www.linkedin.com/in/smalltalk> >> >> >> >> >> On Fri, Oct 26, 2018 at 09:39, 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? >>> >>> Thanks, >>> -Todd > > >

Oct. 27, 2018

Re: [Pharo-dev] About #zipped / #unzipped

by Stephane Ducasse

+1 On Tue, Oct 23, 2018 at 10:50 AM Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > On 18 Oct 2018, at 20:59, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Hi, > > > > Given https://pharo.fogbugz.com/f/cases/21858/Cleanup-remaining-DeprecatedFileSys… [where we need more help !!] I found String>>#zipped to be one of the users of the deprecated RWBinaryOrTextStream. Although this usage is easy enough to fix, I think the current #zipped / #unzipped on String is broken. > > > > (note also that there are no real users of these methods) > > > > Right now it seems cool that the following is an identity. > > > > 'foobar' zipped unzipped. > > > > However, the result of zipping something is actual something binary (a collection of opaque bytes). Thinking of it, the input is actually also bytes, not unencoded characters. > > > > Of course, the current methods are broken, as can be seen from a more complex (wide) string. > > > > 'Ã©lÃ¨ves FranÃ§aises @ 10 â¬' zipped unzipped. >>> <something very weird> > > > > The error results from some implicit/wrong character encoding being used. > > > > The right way to do this is to explicitly encode/decode the string. > > > > (GZipReadStream on: (ByteArray streamContents: [ :out | > > (GZipWriteStream on: out) > > nextPutAll: 'Ã©lÃ¨ves FranÃ§aises Ã 10 â¬' utf8Encoded; > > close ])) upToEnd utf8Decoded. > > > > From this it would follow that #zipped / #unzipped would make more sense on ByteArray. So that the above identity would become. > > > > 'Ã©lÃ¨ves FranÃ§aises Ã 10 â¬' utf8Encoded zipped unzipped utf8Decoded. > > > > This change of signature would be comparable to what we recently did with #base64Encoded / #base64Decoded > > > > What do you think ? > > > > Yes, to me this sounds interestingâ¦ I think compression is indeed better done on the level of bytes then on Strings. > > > Marcus > >

Oct. 26, 2018

Re: [Pharo-dev] Where to discuss strategies and tools for a comeback of Smalltalk using Scratch as entrance

by Stephane Ducasse

Hi Bernhard we are interested in that topics. This is why I wrote the botsinc book in the past and more recently learning OOP with TDD in Pharo book. Now I do not have much resources for the topic. Stef On Fri, Oct 26, 2018 at 2:16 PM Bernhard HÃ¶fner <bernhard.hoefner(a)gmx.de> wrote: > > > Hello Group. I like to discuss about the subject and have also some ideas. But I want to ask first for the proper list within the forum. I heard that there is a discussion ongoing and want to participate. > > > > I will send this question to Squeak and Pharo usegroup and to the Phratch-developer. I assume that there is a common discussion about the subject. Hopefully there is no need to open on each platform an individual thread. > > > > Regards, Bernhard >

Oct. 26, 2018

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

by Stephane Ducasse

go go go! FileReference! On Fri, Oct 26, 2018 at 3:12 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 >

Oct. 26, 2018

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

by Todd Blanchard

That would be super awesome! Please let me know if/when you do. Thanks, -Todd Blanchard > On Oct 26, 2018, at 9:43 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > > I have one. I should see about adding it to a branch. > > .... > John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk <https://www.linkedin.com/in/smalltalk> > > > > > On Fri, Oct 26, 2018 at 09:39, 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? >> >> Thanks, >> -Todd

Oct. 26, 2018

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

by John M McIntosh

I have one. I should see about adding it to a branch. .... John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk On Fri, Oct 26, 2018 at 09:39, 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? > > Thanks, > -Todd

Oct. 26, 2018

Xcode projects for VM on iOS or Mac?

by Todd Blanchard

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? Thanks, -Todd

Oct. 26, 2018