- Pharo-users - lists.pharo.org

Re: Pharo-SQLite3: closing connections immediately and deleting the database file

by JuliÃ¡n Maestri

Not exactly what you are asking for, but did you consider using sqlite in memory? On Sat, 7 Aug 2021 at 23:23, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > I've been doing exactly that. It is, creating a new DB file for each > test, and I was having the same problem as you. > > I suggested a change to the driver to cover that situation: > https://github.com/pharo-rdbms/Pharo-SQLite3/pull/22/files > > Try applying that change and see if that works. > > I still prefer to recreate the database, it will give you a full fresh > start, and if you want you can halt before the deletion of the db, to > analyze its internal state. > > Best regards! > > > Esteban A. Maringolo > > On Sat, Aug 7, 2021 at 11:13 PM <vinref(a)gmail.com> wrote: > > > > Hi > > > > Actually I will just do a bunch of > > > > DROP TABLE IF EXISTS > > > > instead of dropping the db altogether. > > > > Thanks, Vince >

Aug. 12, 2021

ABBench: Lightweight Microbenchmarking Library

by Evan Donahue

Hello, I've just released a utility I've been using for the past few years to help optimize Pharo code. It's a library that makes it easy to check whether an optimization has improved performance by wrapping the optimization and the old code in an if block and executing the optimized and unoptimized paths repeatedly under the same runtime conditions to determine which is faster. Basic usage is to wrap changes to the code in if blocks like so: ABBench a: [ ...existing code...] b: [...optimized code...] And then run the A/B test by printing: ABBench bench: [...some main method...] I have found it to make performance testing simple and quick enough that I actually do it. Perhaps someone else will find it useful. Install with: Metacello new githubUser: 'emdonahue' project: 'ABBench' commitish: 'master' path: ''; baseline: 'ABBench'; load. More details can be found here: https://github.com/emdonahue/ABBench Cheers, Evan

Aug. 12, 2021

Exercism v3 problems

by r.wobben＠home.nl

Hello, For the new version of exercism which is due in a few weeks, the pharo track needs a test-runner, a example of that can be found here : https://github.com/exercism/ruby-test-runner/tree/main/lib first question : Can this be easily be done in pharo? second question : can it also be standalone? Regards, Roelof

Aug. 10, 2021

Re: Logging Frameworks

by Esteban Maringolo

Hi Gabriel, I found this Beacon-Server [1] that could work, it would be a good use case in a docker environment where you have several worker images talking to a single beacon-server-container. Regards! [1] https://github.com/grype/Beacon-Server Esteban A. Maringolo On Mon, Aug 9, 2021 at 9:10 AM Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > Beacon is integrated as part of Pharo now, but the repository includes more logger options. Maybe some option there allows forwarding the logs to a centralized place. I'm also interested in other's experiences regarding logging options because we want to settle on some option as the default for our Pharo components. > > On Sun, Aug 8, 2021 at 11:29 AM Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> What are the current options for logging? >> >> Beacon seems to be the most modern one, but the Github repository >> doesn't seem very active (maybe it forked somewhere else). >> >> Given that the logs might come from different worker images, is there >> something that can work via HTTP or similar? (it is, forwarding the >> logged events to a server). >> >> Regards! >> >> ps: I think I've asked this before, but couldn't find my previous >> question about it. >> >> >> Esteban A. Maringolo

Aug. 9, 2021

Re: Logging Frameworks

by Esteban Maringolo

That is my impression with Beacon, there was a lot of discussion about it and then never heard of it again. Is your code available somewhere? Regards! ps: There is also TinyLogger that works by means of a DynamicVariable, but I liked the idea of using objects instead of just strings for logging (which I'm manually doing now). Esteban A. Maringolo On Mon, Aug 9, 2021 at 9:16 AM Norbert Hartl <norbert(a)hartl.name> wrote: > > Beacon is a sad story. There was a lot of initiative and motivation for loggers which was killed. But it is still a good foundation to build something useful on top of it. I integrated a syslog option when I was working on beacon. In my projects Iâve done a sender to elasticsearch for logging. Beaconâs design allows all of that. After motivation died nobody put some love into it again. Thatâs all! > > Maybe time to pick it up again. But I personally have too much on my plate right now to take another attempt. > > Norbert > > > Am 09.08.2021 um 14:08 schrieb Gabriel Cotelli <g.cotelli(a)gmail.com>: > > Beacon is integrated as part of Pharo now, but the repository includes more logger options. Maybe some option there allows forwarding the logs to a centralized place. I'm also interested in other's experiences regarding logging options because we want to settle on some option as the default for our Pharo components. > > On Sun, Aug 8, 2021 at 11:29 AM Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> What are the current options for logging? >> >> Beacon seems to be the most modern one, but the Github repository >> doesn't seem very active (maybe it forked somewhere else). >> >> Given that the logs might come from different worker images, is there >> something that can work via HTTP or similar? (it is, forwarding the >> logged events to a server). >> >> Regards! >> >> ps: I think I've asked this before, but couldn't find my previous >> question about it. >> >> >> Esteban A. Maringolo > >

Aug. 9, 2021

Re: Logging Frameworks

by Norbert Hartl

Beacon is a sad story. There was a lot of initiative and motivation for loggers which was killed. But it is still a good foundation to build something useful on top of it. I integrated a syslog option when I was working on beacon. In my projects Iâve done a sender to elasticsearch for logging. Beaconâs design allows all of that. After motivation died nobody put some love into it again. Thatâs all! Maybe time to pick it up again. But I personally have too much on my plate right now to take another attempt. Norbert > Am 09.08.2021 um 14:08 schrieb Gabriel Cotelli <g.cotelli(a)gmail.com>: > > Beacon is integrated as part of Pharo now, but the repository includes more logger options. Maybe some option there allows forwarding the logs to a centralized place. I'm also interested in other's experiences regarding logging options because we want to settle on some option as the default for our Pharo components. > > On Sun, Aug 8, 2021 at 11:29 AM Esteban Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: > What are the current options for logging? > > Beacon seems to be the most modern one, but the Github repository > doesn't seem very active (maybe it forked somewhere else). > > Given that the logs might come from different worker images, is there > something that can work via HTTP or similar? (it is, forwarding the > logged events to a server). > > Regards! > > ps: I think I've asked this before, but couldn't find my previous > question about it. > > > Esteban A. Maringolo

Aug. 9, 2021

Re: Logging Frameworks

by Gabriel Cotelli

Beacon is integrated as part of Pharo now, but the repository includes more logger options. Maybe some option there allows forwarding the logs to a centralized place. I'm also interested in other's experiences regarding logging options because we want to settle on some option as the default for our Pharo components. On Sun, Aug 8, 2021 at 11:29 AM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > What are the current options for logging? > > Beacon seems to be the most modern one, but the Github repository > doesn't seem very active (maybe it forked somewhere else). > > Given that the logs might come from different worker images, is there > something that can work via HTTP or similar? (it is, forwarding the > logged events to a server). > > Regards! > > ps: I think I've asked this before, but couldn't find my previous > question about it. > > > Esteban A. Maringolo >

Aug. 9, 2021

Re: Introducing new feature dataTypes for the PolyMath/DataFrame project

by Konrad Hinsen

"Richard O'Keefe" <raoknz(a)gmail.com> writes: > Neither of those use cases actually works. In practice, they do. > Consider the following partial class hierarchy from my Smalltalk system: That's not what I have to deal with in practice. My data comes in as a CSV file or a JSON file, i.e. formats with very shallow data classification. All I can expect to distinguish are strings vs. numbers, plus a few well-defined subsets of each, such as integers, specific constants (nil, true, false), or data recognizable by their format, such as dates. For internal processing, I might then want to redefine a column's data type to be something more specific. In particular, I might want to distinguish between "categorical" (a predefined finite set of string values) vs. "generic string". But most of the classes in a Smalltalk hierarchy just never occur in data frames. It's a simple data structure for simply structured data. > "You might want to compute an average..." But dataType is no use for > that either, as I was at pains to explain. If you have a bunch of > angles expressed as Numbers, you *can* compute an arithmetic mean of > them, but you *shouldn't*, because that's not how you compute the > average of circular measures. I agree. There are many things you shouldn't do for any given dataset but which no formal structure will prevent you from doing. Data science is very much about shallow computations, with automation limited to simple stuff that is then applied to large datasets. Tools like data type analysis are no more than a help for the data scientist, who is the ultimate arbiter of what is or is not OK to do. Think of this as the data equivalent of a spell checker. A spell checker won't recognize bad grammar, but it's still a useful tool to have. Cheers, Konrad.

Aug. 9, 2021

Re: Introducing new feature dataTypes for the PolyMath/DataFrame project

by Richard O'Keefe

Neither of those use cases actually works. Consider the following partial class hierarchy from my Smalltalk system: Object VectorSpace Complex Quaternion Magnitude MagnitudeWithAddition DateAndTime QuasiArithmetic Duration Number AbstractRationalNumber Integer SmallInteger There is a whole fleet of "numeric" things like Matrix3x3 which have some arithmetic properties but which cannot be given a total order consistent with those properties. Complex is one of them. It makes less than no sense to make Complex inherit from Magnitude, so it cannot inherit from Number, This means that the common superclass of 1 and 1 - 2 i is Object. Yet it makes perfect sense to have a column of Gaussian integers some of which have zero imaginary part. So "the dataType is Object means there's an error" fails at the first hurdle. Conversely, the common superclass of 1 and DateAndTime now is MagnitudeWithAddition, which is not Object, but the combination is probably wrong, and the dataType test fails at the second hurdle. "You might want to compute an average..." But dataType is no use for that either, as I was at pains to explain. If you have a bunch of angles expressed as Numbers, you *can* compute an arithmetic mean of them, but you *shouldn't*, because that's not how you compute the average of circular measures. The obvious algorithm (self sum / self size) does not work at all for a collection of DateAndTimes, but the notion of average makes perfect sense and a subtly different algorithm works well. (I wrote a technical report about this, if anyone is interested.) dataType will tell you you CAN take an average when you cannot or should not. dataType will tell you you CAN'T take an average when you really honestly can. The distinctions we need to make are not the distinctions that the class hierarchy makes. For example, how about the distinction between *ordered* factors and *unordered* factors? On Mon, 9 Aug 2021 at 03:03, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > > "Richard O'Keefe" <raoknz(a)gmail.com> writes: > > > My difficulty is that from a statistics/data science perspective, > > it doesn't seem terribly *useful*. > > There are two common use cases in my experience: > > 1) Error checking, most frequently right after reading in a dataset. > A quick look at the data types of all columns shows if it is coherent > with your expectations. If you have a column called "data" of data > type "Object", then most probably something went wrong with parsing > some date format. > > 2) Type checking for specific operations. For example, you might want to > compute an average over all rows for each numerical column in your > dataset. That's easiest to do by selecting columns of the right data > type. > > You are completely right that data type information is not sufficient > for checking for all possible problems, such as unit mismatch. But it > remains a useful tool. > > Cheers, > Konrad.

Aug. 8, 2021

Re: Introducing new feature dataTypes for the PolyMath/DataFrame project

by Konrad Hinsen

"Richard O'Keefe" <raoknz(a)gmail.com> writes: > My difficulty is that from a statistics/data science perspective, > it doesn't seem terribly *useful*. There are two common use cases in my experience: 1) Error checking, most frequently right after reading in a dataset. A quick look at the data types of all columns shows if it is coherent with your expectations. If you have a column called "data" of data type "Object", then most probably something went wrong with parsing some date format. 2) Type checking for specific operations. For example, you might want to compute an average over all rows for each numerical column in your dataset. That's easiest to do by selecting columns of the right data type. You are completely right that data type information is not sufficient for checking for all possible problems, such as unit mismatch. But it remains a useful tool. Cheers, Konrad.

Aug. 8, 2021