- Pharo-dev - lists.pharo.org

[ANN] 900 pull requests closed for Pharo7!

by Marcus Denker

Hi, March 11, we passed 800. Today (just now) we closed 900 full requests! https://github.com/pharo-project/pharo/pulls <https://github.com/pharo-project/pharo/pulls> Marcus

Feb. 23, 2018

Re: [Pharo-dev] control flow graph

by ClÃ©ment Bera

I used that in the past on intermediate representations, I feel it is very useful to directly edit the code of methods with large control flows since when you have many closing brackets ] ] ] ] you never know where to write your code. Now it's specific to some use-cases such as algorithms where you write methods with large control flows, in most methods due to object oriented programming convention the control flow is not that big. In this context other things could be possible (Smart suggestions to move code out of loops, etc.) On Fri, Feb 23, 2018 at 11:37 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi > > I'm experimenting in building a control flow graph of pharo methods > and I would like to know if you have ideas about what we can do > with them to support our development environment. > > Stef > > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Feb. 23, 2018

control flow graph

by Stephane Ducasse

Hi I'm experimenting in building a control flow graph of pharo methods and I would like to know if you have ideas about what we can do with them to support our development environment. Stef

Feb. 23, 2018

Re: [Pharo-dev] Linux installation

by Norbert Hartl

> Am 23.02.2018 um 05:41 schrieb Sean P. DeNigris <sean(a)clipperadams.com>: > > I know we've struggled with this over the years, especially with the 32-bit > libs. But now we have a lot of infrastructure that seems to be successfully > building/running the VM on various flavors - OBS, travis, etc. Shouldn't one > (or all) of these CI tools reliably have the latest installation script > including the 32-bit libs? It seems like we should just link to one of these > sources rather than depend on someone updating a text file, no? > > Is the following just such a source? > https://github.com/pharo-project/pharo-vm/blob/master/scripts/setup-ubuntu.… > > Also, is OBS working? For example, the following gives a 404: > https://download.opensuse.org/repositories/devel:/languages:/pharo/xUbuntu_… > > Finally, if someone is not too particular about which Linux flavor to use on > their (probably headless) server, what is the easiest to install/most stable > for Pharo? OBS should work, the process is in place. This effort got killed slightly because it was not possible to get the current vm sources in a shape you can feed into a process. First it was that pharo-vm was different to opensmalltalk-vm. Now I do not remember but there is still a problem. Esteban can tell. For me this is sad because the way the vm is implemented and managed it seems neither easy to collaborate nor easy to consume the result. And that is needed if you need to feed that in a process like linux packaging. I find this really important, I even spend money on it to be done. Butâ¦. we will see. I know Holger will care to update OBS if the process allows him to do. But he got stuck every single time he tried to do it. For the choice of linux this is either business or religion dependent. If you need professional support for the linux you should choose one of the big ones, I think this is ubuntu or redhat. They all have long term support versions so you donât need to follow the crowd every day. If you need to have multiple different pharos on your machine you might need to go virtual. Having pharo encapsulated in a docker image feels natural and you can be sure that system-wise you can pharo4, pharo5-32bits, pharo6-32bits, pharo6-64bits all in parallel without disturbance. Basically you need not much more than this Dockerfile <snip> # # Pharo6 Dockerfile # FROM ubuntu:16.04 # Add opensuse repository and install pharo6 binary from there RUN \ apt-get update && \ apt-get install -y wget curl unzip inetutils-ping && \ wget -q http://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/x… -O- | apt-key add - && \ echo 'deb http://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/x… ./' > /etc/apt/sources.list.d/pharo6.list && \ dpkg --add-architecture i386 && \ apt-get update && \ apt-get install -y pharo6-32 pharo6-sources-files && \ rm -rf /var/lib/apt/lists/* RUN mkdir -p /pharo-vm/32 \ && cd /pharo-vm/32 \ && curl get.pharo.org/vm70 | bash </snip> It creates a pharo docker image (mine is called pharo6-32) with the OBS linux vm installed and the pharo7 vm downloaded so you can try which one is better. Applications with pharo I do with this <snip> FROM pharo6-32 RUN apt-get update && apt-get install -y curl COPY Project.image start.st /opt/ # Define working directory. WORKDIR /opt # Define default command. #CMD "/usr/bin/pharo6-32" "--mmap" "64m" "/opt/Project.image" "--no-default-preferences" "st" "/opt/start.st" CMD "/pharo-vm/32/pharo" "--mmap" "64m" "/opt/Project.image" "--no-default-preferences" "st" "/opt/start.st" EXPOSE 3000 </snip> So if you have the pharo image as Project.image in the same directory as the Dockerfile then this image is copied into the docker image and when you start it is called. Hope this helps, Norbert

Feb. 23, 2018

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

by ClÃ©ment Bera

On Thu, Feb 22, 2018 at 11:47 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 22 Feb 2018, at 10:41, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > > > > > On Thu, Feb 22, 2018 at 7:52 AM, Stephane Ducasse < > stepharo.self(a)gmail.com> wrote: > > Clement > > > > can you open a bug entry so that we clean this situation? > > > > > > What is the bug? > > Having two selectors doing the same thing is bad and confuses everybody. > So that is a 'bug'. > > > You want to merge the two selectors and break compatibility with > frameworks using the removed one? > > Either we keep on adding cruft (or leaving cruft in place) in the sake of > backwards compatibility or be do something about it. It is not hard to fix > a couple of senders. It could be done more softly with a deprecation. > > Cleanups at the level of Object are particularly valuable. > Ok. Is the nil injection a feature or a bug too ? Should it be removed ? > > > Stef > > > > On Mon, Feb 19, 2018 at 12:43 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > > > Hi, > > > > > > It seems the two methods have exactly the same behavior indeed. > > > valueWithPossibleArgs: anArray > > > valueWithEnoughArguments: anArray > > > > > > One was edited recently but I think it's only to change the comment, > they're > > > both very old. My guess is that there are two for compatibility > purpose (One > > > is the selector that is considered as the most relevant that should be > used, > > > the other one is the one also present in other Smalltalks so we have > it for > > > cross-Smalltalk librairies or something like that), but only one is > really > > > needed. If you need only the concept for SOM-NS you can just implement > one, > > > if you want to be compatible with different Smalltalk lib implement > both. > > > > > > All use-cases of these methods I have found do not inject nils, they > expect > > > the block to have a number of arguments of the block less or equal to > the > > > number of parameters in the argument array. I would say they're used as > > > #cullWithArguments: but for some reason other selector names were > preferred. > > > > > > Now, as you mentioned, these two methods are more than just > > > cullWithArguments: since they inject nils if there are not enough > > > parameters. To me it looks incorrect to do so because then while > debugging > > > your code you will get issues due to those injected nils and it will be > > > tedious for the application programmer to track the problem down to > these > > > two methods. > > > > > > There a few use-cases for nil injection though. Typically when changing > > > existing frameworks in multiple repositories, it may be that during the > > > update process the change to the caller is installed before the change > of > > > the callee, and if the code is actually used (code in UI for instance), > > > injecting nils might avoid system break-down. Another use-case is for > > > compatibility with frameworks using the nil injection, but I can't > find a > > > framework doing that right now. > > > > > > Honestly, I would not implement the nil injection, but maybe some one > else > > > has a different point of view. > > > > > > On Fri, Feb 16, 2018 at 6:25 PM, Stefan Marr <smalltalk(a)stefan-marr.de > > > > > wrote: > > >> > > >> Hi: > > >> > > >> I am trying to understand the different between and perhaps origin of > > >> BlockClosure>>#valueWithPossibleArgs: and > > >> BlockClosure>>#valueWithEnoughArguments: > > >> > > >> I am trying to decide which of the two I need for SOMns. > > >> > > >> The first one has seen more recent changes, when looking at the Pharo > 6.1 > > >> download: > > >> > > >> valueWithPossibleArgs: anArray â> 2/12/2017 StephaneDucasse > > >> valueWithEnoughArguments: anArray â> 3/11/2001 nk > > >> > > >> While they have rather different implementations, they seem to behave > > >> identically, as far as I could tell using the following example: > > >> > > >> blocks := { > > >> [ { } ]. > > >> [:a | { a } ]. > > >> [:a :b | { a. b } ]. > > >> [:a :b :c | { a. b. c } ] > > >> }. > > >> > > >> blocks collect: [:b | b valueWithPossibleArgs: {1}]. > > >> blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}]. > > >> blocks collect: [:b | b valueWithEnoughArguments: {1}]. > > >> blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}]. > > >> > > >> I was also wondering how they relate to #cull:* > > >> > > >> One of the major differences seems to be that valueWithP* and > valueWithE* > > >> are both injecting nil for absent arguments, while normal #value* and > #cull* > > >> methods signal an error. > > >> Is there a specific use case why one wouldnât want to be strict here > as > > >> well, but instead inject nils? > > >> > > >> Any comments or pointer appreciated. > > >> > > >> Thanks > > >> Stefan > > >> > > >> > > >> -- > > >> Stefan Marr > > >> School of Computing, University of Kent > > >> http://stefan-marr.de/research/ > > >> > > >> > > >> > > > > > > > > > > > > -- > > > ClÃ©ment BÃ©ra > > > Pharo consortium engineer > > > https://clementbera.wordpress.com/ > > > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > > > > > > > > > -- > > ClÃ©ment BÃ©ra > > Pharo consortium engineer > > https://clementbera.wordpress.com/ > > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Feb. 23, 2018

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

by Guillermo Polito

++++++999^1000 :) On Fri, Feb 23, 2018 at 7:32 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Thanks Sven > I thought that suddenly I was an idiot. > > > On Thu, Feb 22, 2018 at 11:47 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > >> On 22 Feb 2018, at 10:41, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> > >> > >> > >> On Thu, Feb 22, 2018 at 7:52 AM, Stephane Ducasse < > stepharo.self(a)gmail.com> wrote: > >> Clement > >> > >> can you open a bug entry so that we clean this situation? > >> > >> > >> What is the bug? > > > > Having two selectors doing the same thing is bad and confuses everybody. > So that is a 'bug'. > > > >> You want to merge the two selectors and break compatibility with > frameworks using the removed one? > > > > Either we keep on adding cruft (or leaving cruft in place) in the sake > of backwards compatibility or be do something about it. It is not hard to > fix a couple of senders. It could be done more softly with a deprecation. > > > > Cleanups at the level of Object are particularly valuable. > > > >> Stef > >> > >> On Mon, Feb 19, 2018 at 12:43 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >> > Hi, > >> > > >> > It seems the two methods have exactly the same behavior indeed. > >> > valueWithPossibleArgs: anArray > >> > valueWithEnoughArguments: anArray > >> > > >> > One was edited recently but I think it's only to change the comment, > they're > >> > both very old. My guess is that there are two for compatibility > purpose (One > >> > is the selector that is considered as the most relevant that should > be used, > >> > the other one is the one also present in other Smalltalks so we have > it for > >> > cross-Smalltalk librairies or something like that), but only one is > really > >> > needed. If you need only the concept for SOM-NS you can just > implement one, > >> > if you want to be compatible with different Smalltalk lib implement > both. > >> > > >> > All use-cases of these methods I have found do not inject nils, they > expect > >> > the block to have a number of arguments of the block less or equal to > the > >> > number of parameters in the argument array. I would say they're used > as > >> > #cullWithArguments: but for some reason other selector names were > preferred. > >> > > >> > Now, as you mentioned, these two methods are more than just > >> > cullWithArguments: since they inject nils if there are not enough > >> > parameters. To me it looks incorrect to do so because then while > debugging > >> > your code you will get issues due to those injected nils and it will > be > >> > tedious for the application programmer to track the problem down to > these > >> > two methods. > >> > > >> > There a few use-cases for nil injection though. Typically when > changing > >> > existing frameworks in multiple repositories, it may be that during > the > >> > update process the change to the caller is installed before the > change of > >> > the callee, and if the code is actually used (code in UI for > instance), > >> > injecting nils might avoid system break-down. Another use-case is for > >> > compatibility with frameworks using the nil injection, but I can't > find a > >> > framework doing that right now. > >> > > >> > Honestly, I would not implement the nil injection, but maybe some one > else > >> > has a different point of view. > >> > > >> > On Fri, Feb 16, 2018 at 6:25 PM, Stefan Marr < > smalltalk(a)stefan-marr.de> > >> > wrote: > >> >> > >> >> Hi: > >> >> > >> >> I am trying to understand the different between and perhaps origin of > >> >> BlockClosure>>#valueWithPossibleArgs: and > >> >> BlockClosure>>#valueWithEnoughArguments: > >> >> > >> >> I am trying to decide which of the two I need for SOMns. > >> >> > >> >> The first one has seen more recent changes, when looking at the > Pharo 6.1 > >> >> download: > >> >> > >> >> valueWithPossibleArgs: anArray â> 2/12/2017 StephaneDucasse > >> >> valueWithEnoughArguments: anArray â> 3/11/2001 nk > >> >> > >> >> While they have rather different implementations, they seem to behave > >> >> identically, as far as I could tell using the following example: > >> >> > >> >> blocks := { > >> >> [ { } ]. > >> >> [:a | { a } ]. > >> >> [:a :b | { a. b } ]. > >> >> [:a :b :c | { a. b. c } ] > >> >> }. > >> >> > >> >> blocks collect: [:b | b valueWithPossibleArgs: {1}]. > >> >> blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}]. > >> >> blocks collect: [:b | b valueWithEnoughArguments: {1}]. > >> >> blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}]. > >> >> > >> >> I was also wondering how they relate to #cull:* > >> >> > >> >> One of the major differences seems to be that valueWithP* and > valueWithE* > >> >> are both injecting nil for absent arguments, while normal #value* > and #cull* > >> >> methods signal an error. > >> >> Is there a specific use case why one wouldnât want to be strict here > as > >> >> well, but instead inject nils? > >> >> > >> >> Any comments or pointer appreciated. > >> >> > >> >> Thanks > >> >> Stefan > >> >> > >> >> > >> >> -- > >> >> Stefan Marr > >> >> School of Computing, University of Kent > >> >> http://stefan-marr.de/research/ > >> >> > >> >> > >> >> > >> > > >> > > >> > > >> > -- > >> > ClÃ©ment BÃ©ra > >> > Pharo consortium engineer > >> > https://clementbera.wordpress.com/ > >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > >> > >> > >> > >> > >> -- > >> ClÃ©ment BÃ©ra > >> Pharo consortium engineer > >> https://clementbera.wordpress.com/ > >> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > > > > > -- 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

Feb. 23, 2018

Re: [Pharo-dev] Linux installation

by Sven Van Caekenberghe

> On 23 Feb 2018, at 05:41, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Finally, if someone is not too particular about which Linux flavor to use on > their (probably headless) server, what is the easiest to install/most stable > for Pharo? Ubuntu Server 16.04.3 LTS https://www.ubuntu.com/download/server Most used, best supported, stable. I know not everybody will agree, and that is fine. There are 100s if not 1000s of Linux distros out there. Unless you know very well what you are doing and why, this is the safe choice. Else you can end up on your own, we can't support them all, and you won't find any other users willing to help you. Sven

Feb. 23, 2018

Re: [Pharo-dev] Linux installation

by Stephane Ducasse

Hi sean Yes we should. Now I think that the community does not really realise how much work it is to produce Pharo. And we cannot and will not do everything. At the end of the day, if pharoers are not able to give 30 min of their time to improve then it will stay like that. I mean if marcus, me and other spent time reviewing, fixing typos on the web then it means that object-centric debugger will not show up. You see we have only a limited amount of resources. So this is good to see all these wishes and needs. I have plenty of them too. But at the end of the day when we do the check if pharoers do not contribute then we will have less done. This is as simple as that. Stef On Fri, Feb 23, 2018 at 5:41 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I know we've struggled with this over the years, especially with the 32-bit > libs. But now we have a lot of infrastructure that seems to be successfully > building/running the VM on various flavors - OBS, travis, etc. Shouldn't one > (or all) of these CI tools reliably have the latest installation script > including the 32-bit libs? It seems like we should just link to one of these > sources rather than depend on someone updating a text file, no? > > Is the following just such a source? > https://github.com/pharo-project/pharo-vm/blob/master/scripts/setup-ubuntu.… > > Also, is OBS working? For example, the following gives a 404: > https://download.opensuse.org/repositories/devel:/languages:/pharo/xUbuntu_… > > Finally, if someone is not too particular about which Linux flavor to use on > their (probably headless) server, what is the easiest to install/most stable > for Pharo? > > > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Feb. 23, 2018

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

by Stephane Ducasse

Thanks Sven I thought that suddenly I was an idiot. On Thu, Feb 22, 2018 at 11:47 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 22 Feb 2018, at 10:41, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> >> >> On Thu, Feb 22, 2018 at 7:52 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> Clement >> >> can you open a bug entry so that we clean this situation? >> >> >> What is the bug? > > Having two selectors doing the same thing is bad and confuses everybody. So that is a 'bug'. > >> You want to merge the two selectors and break compatibility with frameworks using the removed one? > > Either we keep on adding cruft (or leaving cruft in place) in the sake of backwards compatibility or be do something about it. It is not hard to fix a couple of senders. It could be done more softly with a deprecation. > > Cleanups at the level of Object are particularly valuable. > >> Stef >> >> On Mon, Feb 19, 2018 at 12:43 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> > Hi, >> > >> > It seems the two methods have exactly the same behavior indeed. >> > valueWithPossibleArgs: anArray >> > valueWithEnoughArguments: anArray >> > >> > One was edited recently but I think it's only to change the comment, they're >> > both very old. My guess is that there are two for compatibility purpose (One >> > is the selector that is considered as the most relevant that should be used, >> > the other one is the one also present in other Smalltalks so we have it for >> > cross-Smalltalk librairies or something like that), but only one is really >> > needed. If you need only the concept for SOM-NS you can just implement one, >> > if you want to be compatible with different Smalltalk lib implement both. >> > >> > All use-cases of these methods I have found do not inject nils, they expect >> > the block to have a number of arguments of the block less or equal to the >> > number of parameters in the argument array. I would say they're used as >> > #cullWithArguments: but for some reason other selector names were preferred. >> > >> > Now, as you mentioned, these two methods are more than just >> > cullWithArguments: since they inject nils if there are not enough >> > parameters. To me it looks incorrect to do so because then while debugging >> > your code you will get issues due to those injected nils and it will be >> > tedious for the application programmer to track the problem down to these >> > two methods. >> > >> > There a few use-cases for nil injection though. Typically when changing >> > existing frameworks in multiple repositories, it may be that during the >> > update process the change to the caller is installed before the change of >> > the callee, and if the code is actually used (code in UI for instance), >> > injecting nils might avoid system break-down. Another use-case is for >> > compatibility with frameworks using the nil injection, but I can't find a >> > framework doing that right now. >> > >> > Honestly, I would not implement the nil injection, but maybe some one else >> > has a different point of view. >> > >> > On Fri, Feb 16, 2018 at 6:25 PM, Stefan Marr <smalltalk(a)stefan-marr.de> >> > wrote: >> >> >> >> Hi: >> >> >> >> I am trying to understand the different between and perhaps origin of >> >> BlockClosure>>#valueWithPossibleArgs: and >> >> BlockClosure>>#valueWithEnoughArguments: >> >> >> >> I am trying to decide which of the two I need for SOMns. >> >> >> >> The first one has seen more recent changes, when looking at the Pharo 6.1 >> >> download: >> >> >> >> valueWithPossibleArgs: anArray â> 2/12/2017 StephaneDucasse >> >> valueWithEnoughArguments: anArray â> 3/11/2001 nk >> >> >> >> While they have rather different implementations, they seem to behave >> >> identically, as far as I could tell using the following example: >> >> >> >> blocks := { >> >> [ { } ]. >> >> [:a | { a } ]. >> >> [:a :b | { a. b } ]. >> >> [:a :b :c | { a. b. c } ] >> >> }. >> >> >> >> blocks collect: [:b | b valueWithPossibleArgs: {1}]. >> >> blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}]. >> >> blocks collect: [:b | b valueWithEnoughArguments: {1}]. >> >> blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}]. >> >> >> >> I was also wondering how they relate to #cull:* >> >> >> >> One of the major differences seems to be that valueWithP* and valueWithE* >> >> are both injecting nil for absent arguments, while normal #value* and #cull* >> >> methods signal an error. >> >> Is there a specific use case why one wouldnât want to be strict here as >> >> well, but instead inject nils? >> >> >> >> Any comments or pointer appreciated. >> >> >> >> Thanks >> >> Stefan >> >> >> >> >> >> -- >> >> Stefan Marr >> >> School of Computing, University of Kent >> >> http://stefan-marr.de/research/ >> >> >> >> >> >> >> > >> > >> > >> > -- >> > ClÃ©ment BÃ©ra >> > Pharo consortium engineer >> > https://clementbera.wordpress.com/ >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq >> >> >> >> >> -- >> ClÃ©ment BÃ©ra >> Pharo consortium engineer >> https://clementbera.wordpress.com/ >> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > >

Feb. 23, 2018

Re: [Pharo-dev] Cleanup of LDAP for Pharo 6/7

by Stephane Ducasse

Thanks for that! On Thu, Feb 22, 2018 at 11:18 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Just as an info: the LDAP packages from > > http://smalltalkhub.com/#!/~PharoExtras/LDAP > > had no method categorization and missing class comments and was > not updated since Pharo 4. > > I took some minutes today to clean this up and I also added a new baseline/version > not loading Zinc (as this is already included) for Pharo 6 and 7. > > The latest config is now also in MetaRepoForPharo60 and with that > should be available for catalog tomorrow for easy consumption after the > catalog indexer runs. > > Thx > Torsten/astares > >

Feb. 23, 2018