Re: [Pharo-users] Traits for class methods?
Cyril Ferlicot wrote: > > I'm not a big fan of limiting the language on composition because the > choice between composition and inheritance should be conceptual and > not technical. > > I read in an article this way to choose between inheritance and composition: An alternative (Smalltalk) view is that inheritance is primarily a code reuse instrument. Use it when it allows you to do so. Java and c++ deformed a lot of OO thinking Stephan
[Pharo-users] Working VM for OS X for Pharo 7
Hi, Where is it possible to get a working OS X VM for Pharo7 ? Accoring to my test, the VM linked at http://pharo.org/download as error with a libgit plugin (same for linux VM btw) Thanks Hilaire -- Dr. Geo http://drgeo.eu
Re: [Pharo-users] Working VM for OS X for Pharo 7
Hi Hilaire, On Thu, 14 Feb 2019 at 09:09, Hilaire wrote: > > Hi, > > Where is it possible to get a working OS X VM for Pharo7 ? > > Accoring to my test, the VM linked at http://pharo.org/download as error > with a libgit plugin (same for linux VM btw) I've been using both the stable and latest VMs on Ubuntu 16.04 without libgit problems "forever" (I don't remember the last time I had problem). Can you provide the path to, and output of "ldd libgit2.so"? Which linux are you using? Cheers, Alistair
Re: [Pharo-users] Working VM for OS X for Pharo 7
I downloaded again the 32bits linux VM, and I can't reproduce this error with a stock P7 image. Now I am still wondering with os x vm because I tried two days ago on a computer at school, and get this libgit plugin error, same error mentionned as well by a Pharoer. Hilaire Le 14/02/2019 à 09:14, Alistair Grant a écrit : > I've been using both the stable and latest VMs on Ubuntu 16.04 without > libgit problems "forever" (I don't remember the last time I had > problem). > > Can you provide the path to, and output of "ldd libgit2.so"? > > Which linux are you using? -- Dr. Geo http://drgeo.eu
Re: [Pharo-users] Working VM for OS X for Pharo 7
Good morning, Last week I had a problem with a conflicting version of libgit installed by brew. In my case, brew had updated the version making it incompatible with the bindings in FFi. Could you check the execution of: DYLD_PRINT_LIBRARIES_POST_LAUNCH=1 ./pharo-vm/Pharo.app/Contents/MacOS/Pharo Pharo.image So we can see the libgit that is loading. This can be fixed in the image side, I remember I fixed a bug in the lookup of libgit. On Thu, 14 Feb 2019, 09:09 Hilaire Hi, > > Where is it possible to get a working OS X VM for Pharo7 ? > > Accoring to my test, the VM linked at http://pharo.org/download as error > with a libgit plugin (same for linux VM btw) > > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > > >
Re: [Pharo-users] Working VM for OS X for Pharo 7
Hopefully I may have access to a mac tomorrow to test your request, or it will be in 10 days. On the other hand, is not libgit integrated in the VM, so I don't understand how it can be related to system update? Or is libgit a binding to a system git or something like that? Thanks PS: I did an update of my linux system a few days ago, so could it fix the issue... Hilaire Le 14/02/2019 à 09:51, teso...@gmail.com a écrit : > Good morning, > Last week I had a problem with a conflicting version of libgit > installed by brew. In my case, brew had updated the version making it > incompatible with the bindings in FFi. > > Could you check the execution of: > > DYLD_PRINT_LIBRARIES_POST_LAUNCH=1 > ./pharo-vm/Pharo.app/Contents/MacOS/Pharo Pharo.image > > > So we can see the libgit that is loading. This can be fixed in the > image side, I remember I fixed a bug in the lookup of libgit. > -- Dr. Geo http://drgeo.eu
Re: [Pharo-users] pathSegments of workingDirectory?
Haha, I didn't pay enough attention to see the difference between
#workingDirectory and #home.
Thanks for the clarification !
BTW, what I also wanted to add is that independent of the precise type you can
always use the instances to do your job (open it, move it, etc ...).
> On 14 Feb 2019, at 08:18, Alistair Grant wrote:
>
> Hi David & Sven,
>
> On Thu, 14 Feb 2019 at 07:46, Sven Van Caekenberghe wrote:
>>
>> David,
>>
>>> On 14 Feb 2019, at 03:56, David Richards
>>> wrote:
>>>
>>> Hi community,
>>>
>>> Consider:
>>>
>>> | file |
>>> file := FileLocator workingDirectory .
>>> file fullName .
>>> "==> '/Users/dr/Documents/Pharo/images/Study (Pharo 7.0 - 64bit stable)'"
>>> file pathSegments .
>>> "==> #()"
>>>
>>> How do we obtain path segments for the working directory?
>>>
>>> Is this an edge case where pathSegments does not return a semantically
>>> consistent value?
>>>
>>> Thanks
>>> David
>>
>> A FileLocator is a bit special, it is usable, but not yet fully realised,
>> more abstract.
>>
>> You can use resolve. Consider:
>>
>> FileLocator home pathString.
>> "'/Users/sven'"
>>
>> FileLocator home resolve pathSegments.
>> "#('Users' 'sven')"
>
> What Sven wrote is, of course, correct. But this is also an edge case:
>
> FileLocator workingDirectory resolve pathSegments.
> "#()"
>
> The reason in this case is because the directory is stored as a
> RelativePath. A RelativePath is resolved against the working
> directory, which in this case is the same thing, so no movement is
> required, and an empty path is used.
>
> You can also try:
>
> FileLocator workingDirectory asAbsolute pathSegments.
> " #('home' 'alistair' 'pharo8' 'pharo64.04')"
>
> Just for added confusion, FileLocator class>>workingDirectory is also
> a special case. Most of the methods in the origins protocol return an
> instance of FileLocator. But FileLocator class>>workingDirectory
> returns an instance of FileReference.
>
> HTH,
> Alistair
Re: [Pharo-users] Working VM for OS X for Pharo 7
On Thu., 14 Feb. 2019, 10:07 Hilaire, wrote: > Hopefully I may have access to a mac tomorrow to test your request, or > it will be in 10 days. > > On the other hand, is not libgit integrated in the VM, so I don't > understand how it can be related to system update? Or is libgit a > binding to a system git or something like that? > On Linux it is almost always: - A library isn't found because the search path is wrong, i.e. LD_LIBRARY_PATH needs to be set, and/or - there's a missing dependency. The ldd command helps track these down by showing which dependencies are missing. On Linux you need to be careful because the pharo script sets up LD_LIBRARY_PATH, so ldd may show something as missing which will be found when pharo is actually run, e.g libssh. Cheers, Alistair (on phone) > >
Re: [Pharo-users] Working VM for OS X for Pharo 7
I know what you are describing, for example cairo can be impacted. My self questioning was: Does the VM rely on the host git library or is the one shipped with the vm sufficient? Best, Hilaire Le 14/02/2019 à 10:33, Alistair Grant a écrit : > On Linux it is almost always: > > - A library isn't found because the search path is wrong, i.e. > LD_LIBRARY_PATH needs to be set, and/or > - there's a missing dependency. > > The ldd command helps track these down by showing which dependencies > are missing. > > On Linux you need to be careful because the pharo script sets > up LD_LIBRARY_PATH, so ldd may show something as missing which will be > found when pharo is actually run, e.g libssh. > > Cheers, > Alistair > (on phone) -- Dr. Geo http://drgeo.eu
[Pharo-users] Quality assistant
Hi How to turn off the quality assitant in the calypso browser? I don't find anymore the option in the settings browser. Hilaire -- Dr. Geo http://drgeo.eu
Re: [Pharo-users] pathSegments of workingDirectory?
Hi Sven,
Your second example expression fails for 'workingDirectory':
FileLocator workingDirectory resolve pathSegments
==> #()
It works fine for FileLocator home but not for FileLocator workingDirectory
.
Your first expression will produce the desired result, if en*source*lled
with syntactimancy:
FileLocator workingDirectory pathString asFileReference pathSegments
This smells a lot like an edge case to me. But perhaps it is the Way of
Smalltalk.
Thanks
David
On Wed, 13 Feb 2019 at 22:46, Sven Van Caekenberghe wrote:
> David,
>
> > On 14 Feb 2019, at 03:56, David Richards
> wrote:
> >
> > Hi community,
> >
> > Consider:
> >
> > | file |
> > file := FileLocator workingDirectory .
> > file fullName .
> > "==> '/Users/dr/Documents/Pharo/images/Study (Pharo 7.0 - 64bit stable)'"
> > file pathSegments .
> > "==> #()"
> >
> > How do we obtain path segments for the working directory?
> >
> > Is this an edge case where pathSegments does not return a semantically
> consistent value?
> >
> > Thanks
> > David
>
> A FileLocator is a bit special, it is usable, but not yet fully realised,
> more abstract.
>
> You can use resolve. Consider:
>
> FileLocator home pathString.
> "'/Users/sven'"
>
> FileLocator home resolve pathSegments.
> "#('Users' 'sven')"
>
> HTH,
>
> Sven
>
>
>
Re: [Pharo-users] pathSegments of workingDirectory?
> On 14 Feb 2019, at 13:55, David Richards
> wrote:
>
> Hi Sven,
>
> Your second example expression fails for 'workingDirectory':
>
> FileLocator workingDirectory resolve pathSegments
> ==> #()
>
> It works fine for FileLocator home but not for FileLocator workingDirectory .
>
> Your first expression will produce the desired result, if ensourcelled with
> syntactimancy:
>
> FileLocator workingDirectory pathString asFileReference pathSegments
>
> This smells a lot like an edge case to me. But perhaps it is the Way of
> Smalltalk.
Like Alistair said, it should be
FileLocator workingDirectory asAbsolute pathSegments.
because it is a relative path.
> Thanks
> David
>
>
>
> On Wed, 13 Feb 2019 at 22:46, Sven Van Caekenberghe wrote:
> David,
>
> > On 14 Feb 2019, at 03:56, David Richards
> > wrote:
> >
> > Hi community,
> >
> > Consider:
> >
> > | file |
> > file := FileLocator workingDirectory .
> > file fullName .
> > "==> '/Users/dr/Documents/Pharo/images/Study (Pharo 7.0 - 64bit stable)'"
> > file pathSegments .
> > "==> #()"
> >
> > How do we obtain path segments for the working directory?
> >
> > Is this an edge case where pathSegments does not return a semantically
> > consistent value?
> >
> > Thanks
> > David
>
> A FileLocator is a bit special, it is usable, but not yet fully realised,
> more abstract.
>
> You can use resolve. Consider:
>
> FileLocator home pathString.
> "'/Users/sven'"
>
> FileLocator home resolve pathSegments.
> "#('Users' 'sven')"
>
> HTH,
>
> Sven
>
>
[Pharo-users] How do I find the RPackageTag of a class?
I’m trying to understand how RPackage and RPackageTag work in Pharo7? It seems different than Pharo6 at least with Nautilus (vs Calypso) - as previously the Nautilus UI gave me the RPacakgeTag, and I could just work with that. Calypso doesn’t seem to give me the tag object, but if I have a known class and I want to know its RPackageTag I can’t see how you do it? It all seems rather messy…. I can ask a class for its category - which just gives me a symbol of the form “mypackage-tagname”, and if I ask a class for its package, it will give me an RPackage(myPackage) - but that RPackage has a set of RPackageTags which just use the tagname (so not prefixed with "mypackage-“)? So am I really supposed to split the category name on “-“ myself, and then select the correct RPackageTag? If I look at the RPackageTag tests - they all seem to use hard coded values and so don’t really show you how you deal with the question above? It really seems quite messy? I naively thought that if I wanted a browser extension to deal with a selected package tag - and file out some classes in that tag (for exercism) - I could easily get the RPackageTag from any class and then use it? Tim
Re: [Pharo-users] How do I find the RPackageTag of a class?
Actually - I’ve realised that Calypso can give me the tag name from its context - (aToolContext lastSelectedClassGroup). However it does highlight a very strange package/tag design. Are you not supposed to be easily able to derive RPacakgeTags? Tim > On 14 Feb 2019, at 13:19, Tim Mackinnon wrote: > > I’m trying to understand how RPackage and RPackageTag work in Pharo7? It > seems different than Pharo6 at least with Nautilus (vs Calypso) - as > previously the Nautilus UI gave me the RPacakgeTag, and I could just work > with that. Calypso doesn’t seem to give me the tag object, but if I have a > known class and I want to know its RPackageTag I can’t see how you do it? It > all seems rather messy…. > > I can ask a class for its category - which just gives me a symbol of the form > “mypackage-tagname”, and if I ask a class for its package, it will give me an > RPackage(myPackage) - but that RPackage has a set of RPackageTags which just > use the tagname (so not prefixed with "mypackage-“)? So am I really supposed > to split the category name on “-“ myself, and then select the correct > RPackageTag? > > If I look at the RPackageTag tests - they all seem to use hard coded values > and so don’t really show you how you deal with the question above? > > It really seems quite messy? > > I naively thought that if I wanted a browser extension to deal with a > selected package tag - and file out some classes in that tag (for exercism) - > I could easily get the RPackageTag from any class and then use it? > > Tim
Re: [Pharo-users] Status of XML Support's move to GitHub
Hi again, > On 10 Jan 2019, at 16:31, Sven Van Caekenberghe wrote: > > Hi, > > What is the status of XML Support's move to GitHub ? > Many people were pro, has anything been done ? > It would be very nice. > > Sven I did https://github.com/svenvc/XML-Support-Pharo as a direct copy of the code from SmalltalkHub to GitHub, Tonel, Pharo and Travis CI. This is just the bare minimum, a proof of concept, with new, much simplified baselines. It was the last project that I depend on and I wanted it in GitHub for my own purposes. The default load of XMLParser includes XMLWriter, the tests and the GT extensions. All 5100+ tests are green. I am using Pharo 7.0.1 64-bit. Code seems to load reasonably fast. I want to stress that this is not a fork, nor the end of this conversion. I have a lot of respect for this high quality, solid code base and want this important piece of code to move forward. I hope others will help. Sven
Re: [Pharo-users] pathSegments of workingDirectory?
Perfect.
Many thanks.
On Thu, 14 Feb 2019 at 05:14, Sven Van Caekenberghe wrote:
>
>
> > On 14 Feb 2019, at 13:55, David Richards
> wrote:
> >
> > Hi Sven,
> >
> > Your second example expression fails for 'workingDirectory':
> >
> > FileLocator workingDirectory resolve pathSegments
> > ==> #()
> >
> > It works fine for FileLocator home but not for FileLocator
> workingDirectory .
> >
> > Your first expression will produce the desired result, if ensourcelled
> with syntactimancy:
> >
> > FileLocator workingDirectory pathString asFileReference pathSegments
> >
> > This smells a lot like an edge case to me. But perhaps it is the Way of
> Smalltalk.
>
> Like Alistair said, it should be
>
> FileLocator workingDirectory asAbsolute pathSegments.
>
> because it is a relative path.
>
> > Thanks
> > David
> >
> >
> >
> > On Wed, 13 Feb 2019 at 22:46, Sven Van Caekenberghe
> wrote:
> > David,
> >
> > > On 14 Feb 2019, at 03:56, David Richards <
> david.i.richards@gmail.com> wrote:
> > >
> > > Hi community,
> > >
> > > Consider:
> > >
> > > | file |
> > > file := FileLocator workingDirectory .
> > > file fullName .
> > > "==> '/Users/dr/Documents/Pharo/images/Study (Pharo 7.0 - 64bit
> stable)'"
> > > file pathSegments .
> > > "==> #()"
> > >
> > > How do we obtain path segments for the working directory?
> > >
> > > Is this an edge case where pathSegments does not return a semantically
> consistent value?
> > >
> > > Thanks
> > > David
> >
> > A FileLocator is a bit special, it is usable, but not yet fully
> realised, more abstract.
> >
> > You can use resolve. Consider:
> >
> > FileLocator home pathString.
> > "'/Users/sven'"
> >
> > FileLocator home resolve pathSegments.
> > "#('Users' 'sven')"
> >
> > HTH,
> >
> > Sven
> >
> >
>
>
>
Re: [Pharo-users] Status of XML Support's move to GitHub
Hi Sven, Can we use filetree/cypress for this for now? IF the intention is for your copy to become the canonical github one at least. Squeak and GemStone don't yet have tonel and the smalltalkhub/PharoExtras repo is where code is currently loaded from for those platforms. Thanks for giving it some thought. Paul Sven Van Caekenberghe-2 wrote > Hi again, > >> On 10 Jan 2019, at 16:31, Sven Van Caekenberghe < > sven@ > > wrote: >> >> Hi, >> >> What is the status of XML Support's move to GitHub ? >> Many people were pro, has anything been done ? >> It would be very nice. >> >> Sven > > I did https://github.com/svenvc/XML-Support-Pharo as a direct copy of the > code from SmalltalkHub to GitHub, Tonel, Pharo and Travis CI. > > This is just the bare minimum, a proof of concept, with new, much > simplified baselines. It was the last project that I depend on and I > wanted it in GitHub for my own purposes. The default load of XMLParser > includes XMLWriter, the tests and the GT extensions. > > All 5100+ tests are green. I am using Pharo 7.0.1 64-bit. Code seems to > load reasonably fast. > > I want to stress that this is not a fork, nor the end of this conversion. > > I have a lot of respect for this high quality, solid code base and want > this important piece of code to move forward. > > I hope others will help. > > Sven -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Re: [Pharo-users] Status of XML Support's move to GitHub
Paul, Like I said, this is just a simple first POC for Pharo only. Of course, the real version should probably not use Tonel, and include the history. I just do not want to take this on, I have already too many public things to support. It is however my opinion that supporting multiple architectures and all kinds of older/historic variants make things exponentially more complex, and this is holding us back - I sometimes feel this in my other projects as well. But this is a general remark, not about XML Support (which has a different history). Sven > On 14 Feb 2019, at 18:08, Paul DeBruicker wrote: > > Hi Sven, > > Can we use filetree/cypress for this for now? IF the intention is for your > copy to become the canonical github one at least. Squeak and GemStone > don't yet have tonel and the smalltalkhub/PharoExtras repo is where code is > currently loaded from for those platforms. > > > Thanks for giving it some thought. > > Paul > > > > Sven Van Caekenberghe-2 wrote >> Hi again, >> >>> On 10 Jan 2019, at 16:31, Sven Van Caekenberghe < > >> sven@ > >> > wrote: >>> >>> Hi, >>> >>> What is the status of XML Support's move to GitHub ? >>> Many people were pro, has anything been done ? >>> It would be very nice. >>> >>> Sven >> >> I did https://github.com/svenvc/XML-Support-Pharo as a direct copy of the >> code from SmalltalkHub to GitHub, Tonel, Pharo and Travis CI. >> >> This is just the bare minimum, a proof of concept, with new, much >> simplified baselines. It was the last project that I depend on and I >> wanted it in GitHub for my own purposes. The default load of XMLParser >> includes XMLWriter, the tests and the GT extensions. >> >> All 5100+ tests are green. I am using Pharo 7.0.1 64-bit. Code seems to >> load reasonably fast. >> >> I want to stress that this is not a fork, nor the end of this conversion. >> >> I have a lot of respect for this high quality, solid code base and want >> this important piece of code to move forward. >> >> I hope others will help. >> >> Sven > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Re: [Pharo-users] Status of XML Support's move to GitHub
Hi, but Tonel allows to use the package also on Windows platform as Tonel is more compact. Otherwise we will run into long filename git trouble again. This would limit it's use. A filetree/cypress might make sense for other dialects - but due to the above would it be possibly to have these formats as a separate branch and keep the master in Tonel? I know this makes it harder in maintaining - but I'm not sure the XML packages changes so often. @Sven: thank for taking action. Can we have a link in the README pointing also to the original STHub Repo? Maybe we should move the canonical project to the more central https://github.com/pharo-contributions like it was done with other repos and add Sven (and others interested) to this team. Thanks T. > Gesendet: Donnerstag, 14. Februar 2019 um 18:08 Uhr > Von: "Paul DeBruicker" > An: pharo-users@lists.pharo.org > Betreff: Re: [Pharo-users] Status of XML Support's move to GitHub > > Hi Sven, > > Can we use filetree/cypress for this for now? IF the intention is for your > copy to become the canonical github one at least. Squeak and GemStone > don't yet have tonel and the smalltalkhub/PharoExtras repo is where code is > currently loaded from for those platforms. > > > Thanks for giving it some thought. > > Paul > > > > Sven Van Caekenberghe-2 wrote > > Hi again, > > > >> On 10 Jan 2019, at 16:31, Sven Van Caekenberghe < > > > sven@ > > > > wrote: > >> > >> Hi, > >> > >> What is the status of XML Support's move to GitHub ? > >> Many people were pro, has anything been done ? > >> It would be very nice. > >> > >> Sven > > > > I did https://github.com/svenvc/XML-Support-Pharo as a direct copy of the > > code from SmalltalkHub to GitHub, Tonel, Pharo and Travis CI. > > > > This is just the bare minimum, a proof of concept, with new, much > > simplified baselines. It was the last project that I depend on and I > > wanted it in GitHub for my own purposes. The default load of XMLParser > > includes XMLWriter, the tests and the GT extensions. > > > > All 5100+ tests are green. I am using Pharo 7.0.1 64-bit. Code seems to > > load reasonably fast. > > > > I want to stress that this is not a fork, nor the end of this conversion. > > > > I have a lot of respect for this high quality, solid code base and want > > this important piece of code to move forward. > > > > I hope others will help. > > > > Sven > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >
Re: [Pharo-users] Status of XML Support's move to GitHub
> On 14 Feb 2019, at 19:02, Torsten Bergmann wrote: > > Hi, > > but Tonel allows to use the package also on Windows platform as Tonel is more > compact. Otherwise we will run into long filename git > trouble again. This would limit it's use. > > A filetree/cypress might make sense for other dialects - but due to the above > would it be possibly to have these formats > as a separate branch and keep the master in Tonel? Sure, there is a reason for Tonel, it *is* better, but in this case it might not be the best choice. > I know this makes it harder in maintaining - but I'm not sure the XML > packages changes so often. No, I don't think they do. > @Sven: thank for taking action. Can we have a link in the README pointing > also to the original STHub Repo? I did. > Maybe we should move the canonical project to the more central > https://github.com/pharo-contributions like it was > done with other repos and add Sven (and others interested) to this team. Once somebody tries to do a real conversion with history. > Thanks > T. > > >> Gesendet: Donnerstag, 14. Februar 2019 um 18:08 Uhr >> Von: "Paul DeBruicker" >> An: pharo-users@lists.pharo.org >> Betreff: Re: [Pharo-users] Status of XML Support's move to GitHub >> >> Hi Sven, >> >> Can we use filetree/cypress for this for now? IF the intention is for your >> copy to become the canonical github one at least. Squeak and GemStone >> don't yet have tonel and the smalltalkhub/PharoExtras repo is where code is >> currently loaded from for those platforms. >> >> >> Thanks for giving it some thought. >> >> Paul >> >> >> >> Sven Van Caekenberghe-2 wrote >>> Hi again, >>> On 10 Jan 2019, at 16:31, Sven Van Caekenberghe < >> >>> sven@ >> wrote: Hi, What is the status of XML Support's move to GitHub ? Many people were pro, has anything been done ? It would be very nice. Sven >>> >>> I did https://github.com/svenvc/XML-Support-Pharo as a direct copy of the >>> code from SmalltalkHub to GitHub, Tonel, Pharo and Travis CI. >>> >>> This is just the bare minimum, a proof of concept, with new, much >>> simplified baselines. It was the last project that I depend on and I >>> wanted it in GitHub for my own purposes. The default load of XMLParser >>> includes XMLWriter, the tests and the GT extensions. >>> >>> All 5100+ tests are green. I am using Pharo 7.0.1 64-bit. Code seems to >>> load reasonably fast. >>> >>> I want to stress that this is not a fork, nor the end of this conversion. >>> >>> I have a lot of respect for this high quality, solid code base and want >>> this important piece of code to move forward. >>> >>> I hope others will help. >>> >>> Sven >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> >
Re: [Pharo-users] Status of XML Support's move to GitHub
Isn’t tonel an open format? Would this not encourage other dialects to adopt it as well? The sooner the better? We know that filetree wasn’t really a great idea as a format (as Windows issues show). I’d say in this case move to it and let’s move forward. Hopefully all together. Tim Sent from my iPhone > On 14 Feb 2019, at 18:43, Sven Van Caekenberghe wrote: > > > >> On 14 Feb 2019, at 19:02, Torsten Bergmann wrote: >> >> Hi, >> >> but Tonel allows to use the package also on Windows platform as Tonel is >> more compact. Otherwise we will run into long filename git >> trouble again. This would limit it's use. >> >> A filetree/cypress might make sense for other dialects - but due to the >> above would it be possibly to have these formats >> as a separate branch and keep the master in Tonel? > > Sure, there is a reason for Tonel, it *is* better, but in this case it might > not be the best choice. > >> I know this makes it harder in maintaining - but I'm not sure the XML >> packages changes so often. > > No, I don't think they do. > >> @Sven: thank for taking action. Can we have a link in the README pointing >> also to the original STHub Repo? > > I did. > >> Maybe we should move the canonical project to the more central >> https://github.com/pharo-contributions like it was >> done with other repos and add Sven (and others interested) to this team. > > Once somebody tries to do a real conversion with history. > >> Thanks >> T. >> >> >>> Gesendet: Donnerstag, 14. Februar 2019 um 18:08 Uhr >>> Von: "Paul DeBruicker" >>> An: pharo-users@lists.pharo.org >>> Betreff: Re: [Pharo-users] Status of XML Support's move to GitHub >>> >>> Hi Sven, >>> >>> Can we use filetree/cypress for this for now? IF the intention is for your >>> copy to become the canonical github one at least. Squeak and GemStone >>> don't yet have tonel and the smalltalkhub/PharoExtras repo is where code is >>> currently loaded from for those platforms. >>> >>> >>> Thanks for giving it some thought. >>> >>> Paul >>> >>> >>> >>> Sven Van Caekenberghe-2 wrote Hi again, > On 10 Jan 2019, at 16:31, Sven Van Caekenberghe < >>> sven@ >>> > wrote: > > Hi, > > What is the status of XML Support's move to GitHub ? > Many people were pro, has anything been done ? > It would be very nice. > > Sven I did https://github.com/svenvc/XML-Support-Pharo as a direct copy of the code from SmalltalkHub to GitHub, Tonel, Pharo and Travis CI. This is just the bare minimum, a proof of concept, with new, much simplified baselines. It was the last project that I depend on and I wanted it in GitHub for my own purposes. The default load of XMLParser includes XMLWriter, the tests and the GT extensions. All 5100+ tests are green. I am using Pharo 7.0.1 64-bit. Code seems to load reasonably fast. I want to stress that this is not a fork, nor the end of this conversion. I have a lot of respect for this high quality, solid code base and want this important piece of code to move forward. I hope others will help. Sven >>> >>> >>> >>> >>> >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >>> >> > >
Re: [Pharo-users] [ANN] P3 version 1.2
Thank you Sven. The timing is perfect. https://blog.digitalocean.com/announcing-managed-databases-for-postgresql/ :) Esteban A. Maringolo El mar., 12 feb. 2019 a las 11:23, Sven Van Caekenberghe () escribió: > > Hi, > > There is a new release of P3, the modern, lean and mean PostgreSQL client for > Pharo. > > https://github.com/svenvc/P3 > > Version 1.2 contains the following changes: > > - P3PreparedStatement is now joined by a polymorphic P3FormattedStatement > working client side on text strings > - P3PreparedStatement & P3FormattedStatement now share the same double > dispatch mechanism to process argument binding > - Added convenience methods #listDatabases #listSchemas & > #listTablesInSchema: to P3Client > - Added convenience methods #firstColumnData & #firstFieldOfFirstRecord to > P3Result > - Added dynamic ENUM support via #loadEnums in P3Client > - Add support for the 7 geometric types POINT, CIRCLE, LINE, LSEG, POLYGON & > PATH with corresponding objects P3Point, P3Circle, P3Line, P3LineSegment, > P3Polygon & P3Path > - Add support for the INTERVAL type with P3Interval object > - Added P3Client>>#serverVersion accessor > - Add support for BIT & VARBIT types with P3FixedBitString & P3BitString > objects > - Add TIMETZ support > - Organised P3 package with tags > - More & better documentation & unit tests > > https://github.com/svenvc/P3/releases/tag/v1.2 > > The quality of open source software is determined by it being alive, > supported and maintained. > > The first way to help is to simply use P3 in your projects and report back > about your successes and the issues that you encounter. You can ask questions > on the Pharo mailing lists. > > Enjoy, > > Sven > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > >
Re: [Pharo-users] [ANN] P3 version 1.2
> On 14 Feb 2019, at 22:44, Esteban Maringolo wrote: > > Thank you Sven. > > The timing is perfect. > https://blog.digitalocean.com/announcing-managed-databases-for-postgresql/ > > :) Interesting & cool; thanks for sharing. > Esteban A. Maringolo > > > El mar., 12 feb. 2019 a las 11:23, Sven Van Caekenberghe > () escribió: >> >> Hi, >> >> There is a new release of P3, the modern, lean and mean PostgreSQL client >> for Pharo. >> >> https://github.com/svenvc/P3 >> >> Version 1.2 contains the following changes: >> >> - P3PreparedStatement is now joined by a polymorphic P3FormattedStatement >> working client side on text strings >> - P3PreparedStatement & P3FormattedStatement now share the same double >> dispatch mechanism to process argument binding >> - Added convenience methods #listDatabases #listSchemas & >> #listTablesInSchema: to P3Client >> - Added convenience methods #firstColumnData & #firstFieldOfFirstRecord to >> P3Result >> - Added dynamic ENUM support via #loadEnums in P3Client >> - Add support for the 7 geometric types POINT, CIRCLE, LINE, LSEG, POLYGON & >> PATH with corresponding objects P3Point, P3Circle, P3Line, P3LineSegment, >> P3Polygon & P3Path >> - Add support for the INTERVAL type with P3Interval object >> - Added P3Client>>#serverVersion accessor >> - Add support for BIT & VARBIT types with P3FixedBitString & P3BitString >> objects >> - Add TIMETZ support >> - Organised P3 package with tags >> - More & better documentation & unit tests >> >> https://github.com/svenvc/P3/releases/tag/v1.2 >> >> The quality of open source software is determined by it being alive, >> supported and maintained. >> >> The first way to help is to simply use P3 in your projects and report back >> about your successes and the issues that you encounter. You can ask >> questions on the Pharo mailing lists. >> >> Enjoy, >> >> Sven >> >> -- >> Sven Van Caekenberghe >> Proudly supporting Pharo >> http://pharo.org >> http://association.pharo.org >> http://consortium.pharo.org >> >> >> >> >> >
