- Pharo-users - lists.pharo.org

Re: [Pharo-users] Is it possible to change the Pharo application title bar?

by Tim Mackinnon

Thats perfectâ¦ so flexible. > On 23 Jul 2017, at 09:15, Henrik Nergaard <draagren(a)outlook.com <mailto:draagren@outlook.com>> wrote: > > DisplayScreen hostWindowTitle: 'NewTitle' > > Best regards, > Henrik > Fra: Pharo-users <pharo-users-bounces(a)lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org>> pÃ¥ vegne av Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> > Sendt: 22. juli 2017 18:44:46 > Til: Pharo Users Newsgroup > Emne: [Pharo-users] Is it possible to change the Pharo application title bar? > > Hi - is it possible to easily change the Pharo.image title bar in the pharo application? (As in the OSX title bar, or Windows one). > > I find that I often have multiple images running and its difficult to distinguish them - so having a title that had the immediate path of the image would be very useful. Iâd prefer not to have to rename image files (althoughI guess could if its not easy to change the title). > > Tim

July 23, 2017

Re: [Pharo-users] NeoCSV change proposal

by Peter Uhnak

Thank you Sven! Peter On Sun, Jul 23, 2017 at 01:59:41PM +0200, Sven Van Caekenberghe wrote: > > > On 23 Jul 2017, at 09:55, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > > Ah, ByteArrayMap, I was trying ByteArray. > > ByteArrayMap is not a class, it is still a ByteArray, but of size 256 used as an inclusion map for characters that fit a byte. > > BTW, using CharacterSet as an abstraction makes the trick easier. > > I committed: > > === > Name: Neo-CSV-Core-SvenVanCaekenberghe.26 > Author: SvenVanCaekenberghe > Time: 23 July 2017, 1:54:22.095185 pm > UUID: e429f87e-5c11-0d00-a72d-ae5d00db2a8c > Ancestors: Neo-CSV-Core-PeterUhnak.25 > > make the core test in #writeOptionalQuotedField faster by using a primitive when possible > > add #testWideOptionalQuoted > === > Name: Neo-CSV-Tests-SvenVanCaekenberghe.22 > Author: SvenVanCaekenberghe > Time: 23 July 2017, 1:54:52.133003 pm > UUID: 5f81c280-5c11-0d00-a72e-7cd500db2a8c > Ancestors: Neo-CSV-Tests-PeterUhnak.21 > > make the core test in #writeOptionalQuotedField faster by using a primitive when possible > > add #testWideOptionalQuoted > === > > Extra caution was needed for WideStrings. > > Sven > > > Not sure what the next step is here: should I add it and send you mczs, or will you do it yourself? (it is a simple change). > > > > Peter > > > > On Sat, Jul 22, 2017 at 10:51:42PM +0200, Sven Van Caekenberghe wrote: > >> Peter, > >> > >>> On 22 Jul 2017, at 22:27, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >>> > >>> Hi Sven, > >>> > >>> my use case was hand-edited CSVs (therefore the quotes are extra clutter), which imples that I would be hand-viewing/editing only small CSVs (no performance issues). > >>> > >>> I agree that we should err on the safe side with CR & LF (e.g. tools may sometimes autoconvert line endings). > >>> > >>> Regarding performance: > >>> > >>> #findFirstInString:inSet:startingAt: didn't work for me (not sure if bug, or I don't know how to use), so I've trried with inCharacterSet: > >> > >> Yes, it is a bitch to use, the the version you used does not use the primitive. > >> > >> Try playing with this: > >> > >> s10 := 'a' repeat: 10. > >> s100 := 'a' repeat: 100. > >> > >> searchSet := ByteArray new: 256 withAll: 0. > >> ',"', String crlf do: [ :each | searchSet at: each asInteger + 1 put: 1 ]. > >> > >> searchSet := (CharacterSet newFrom: ',"', String crlf) byteArrayMap. > >> > >> [ ByteString findFirstInString: s10 inSet: searchSet startingAt: 1 ] bench. > >> "15,160,161 per second" > >> [ ByteString findFirstInString: s100 inSet: searchSet startingAt: 1 ] bench. > >> "8,219,081 per second" > >> > >> ByteString findFirstInString: ',"', String crlf inSet: searchSet startingAt: 1. > >> > >> Sven > >> > >>> Tested on worst-case scenario - strings don't contain tested symbols. > >>> > >>> s10 := 'a' repeat: 10. > >>> s100 := 'a' repeat: 100. > >>> > >>> [ {'"'. ','. String cr. String lf } anySatisfy: [ :each | s10 includesSubstring: each ] ] bench. "'1,200,046 per second'" > >>> [ {'"'. ','. String cr. String lf } anySatisfy: [ :each | s100 includesSubstring: each ] ] bench. "'495,482 per second'" > >>> > >>> [ s10 includesAny: { $,. $". Character cr. Character lf } ] bench. "'2,819,416 per second'" > >>> [ s100 includesAny: { $,. $". Character cr. Character lf } ] bench. "'2,200,668 per second'" > >>> > >>> [ ByteString findFirstInString: s10 inCharacterSet: ',"', String crlf startingAt: 1 ] bench. "'1,187,324 per second'" > >>> [ ByteString findFirstInString: s100 inCharacterSet: ',"', String crlf startingAt: 1 ] bench. "'165,526 per second'" > >>> > >>> > >>> #includesAny: seems to be the best by far. > >>> > >>> Storing the tested characters didn't improve it by much. > >>> > >>> Peter > >>> > >>> On Sat, Jul 22, 2017 at 06:51:31PM +0200, Sven Van Caekenberghe wrote: > >>>> Hi Peter, > >>>> > >>>>> On 22 Jul 2017, at 14:12, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> this is a continuation of an older thread about quoting fields only when necessary. ( http://forum.world.st/NeoCSVWriter-automatic-quotes-td4924781.html ) > >>>>> > >>>>> I've attached fileouts of NeoCSV packages with the addition (I don't know if Metacello can file-out only changesets). > >>>>> > >>>>> The change doesn't affect the default behavior, only when explicitly requested. > >>>>> > >>>>> Peter > >>>> > >>>> I accepted your changes as such, the .mcz's were copied over to the main repositories. This is a pure & clean extension, so that is good. Thank you. > >>>> > >>>> This option is always going to be slower, but the current implementation might be improved, I think. > >>>> > >>>> The key test in #writeOptionalQuotedField: > >>>> > >>>> { > >>>> lineEnd asString. > >>>> separator asString. > >>>> '"' } anySatisfy: [ :each | string includesSubstring: each ] > >>>> > >>>> will be quite slow. > >>>> > >>>> If we accept a little bit of (over safe) error on EOL and use any occurrence of CR or LF as needing a quote, we could switch to characters to test for. There exists a fast (primitive) test, #findFirstInString:inSet:startingAt: that can do all the testing in one go. If your version turns out to be slow, we could try that, if measurements show a difference. > >>>> > >>>> Regards, > >>>> > >>>> Sven > >>>> > >>>> > >>> > >> > >> > > > >

July 23, 2017

Re: [Pharo-users] NeoCSV change proposal

by Sven Van Caekenberghe

> On 23 Jul 2017, at 09:55, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Ah, ByteArrayMap, I was trying ByteArray. ByteArrayMap is not a class, it is still a ByteArray, but of size 256 used as an inclusion map for characters that fit a byte. BTW, using CharacterSet as an abstraction makes the trick easier. I committed: === Name: Neo-CSV-Core-SvenVanCaekenberghe.26 Author: SvenVanCaekenberghe Time: 23 July 2017, 1:54:22.095185 pm UUID: e429f87e-5c11-0d00-a72d-ae5d00db2a8c Ancestors: Neo-CSV-Core-PeterUhnak.25 make the core test in #writeOptionalQuotedField faster by using a primitive when possible add #testWideOptionalQuoted === Name: Neo-CSV-Tests-SvenVanCaekenberghe.22 Author: SvenVanCaekenberghe Time: 23 July 2017, 1:54:52.133003 pm UUID: 5f81c280-5c11-0d00-a72e-7cd500db2a8c Ancestors: Neo-CSV-Tests-PeterUhnak.21 make the core test in #writeOptionalQuotedField faster by using a primitive when possible add #testWideOptionalQuoted === Extra caution was needed for WideStrings. Sven > Not sure what the next step is here: should I add it and send you mczs, or will you do it yourself? (it is a simple change). > > Peter > > On Sat, Jul 22, 2017 at 10:51:42PM +0200, Sven Van Caekenberghe wrote: >> Peter, >> >>> On 22 Jul 2017, at 22:27, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>> >>> Hi Sven, >>> >>> my use case was hand-edited CSVs (therefore the quotes are extra clutter), which imples that I would be hand-viewing/editing only small CSVs (no performance issues). >>> >>> I agree that we should err on the safe side with CR & LF (e.g. tools may sometimes autoconvert line endings). >>> >>> Regarding performance: >>> >>> #findFirstInString:inSet:startingAt: didn't work for me (not sure if bug, or I don't know how to use), so I've trried with inCharacterSet: >> >> Yes, it is a bitch to use, the the version you used does not use the primitive. >> >> Try playing with this: >> >> s10 := 'a' repeat: 10. >> s100 := 'a' repeat: 100. >> >> searchSet := ByteArray new: 256 withAll: 0. >> ',"', String crlf do: [ :each | searchSet at: each asInteger + 1 put: 1 ]. >> >> searchSet := (CharacterSet newFrom: ',"', String crlf) byteArrayMap. >> >> [ ByteString findFirstInString: s10 inSet: searchSet startingAt: 1 ] bench. >> "15,160,161 per second" >> [ ByteString findFirstInString: s100 inSet: searchSet startingAt: 1 ] bench. >> "8,219,081 per second" >> >> ByteString findFirstInString: ',"', String crlf inSet: searchSet startingAt: 1. >> >> Sven >> >>> Tested on worst-case scenario - strings don't contain tested symbols. >>> >>> s10 := 'a' repeat: 10. >>> s100 := 'a' repeat: 100. >>> >>> [ {'"'. ','. String cr. String lf } anySatisfy: [ :each | s10 includesSubstring: each ] ] bench. "'1,200,046 per second'" >>> [ {'"'. ','. String cr. String lf } anySatisfy: [ :each | s100 includesSubstring: each ] ] bench. "'495,482 per second'" >>> >>> [ s10 includesAny: { $,. $". Character cr. Character lf } ] bench. "'2,819,416 per second'" >>> [ s100 includesAny: { $,. $". Character cr. Character lf } ] bench. "'2,200,668 per second'" >>> >>> [ ByteString findFirstInString: s10 inCharacterSet: ',"', String crlf startingAt: 1 ] bench. "'1,187,324 per second'" >>> [ ByteString findFirstInString: s100 inCharacterSet: ',"', String crlf startingAt: 1 ] bench. "'165,526 per second'" >>> >>> >>> #includesAny: seems to be the best by far. >>> >>> Storing the tested characters didn't improve it by much. >>> >>> Peter >>> >>> On Sat, Jul 22, 2017 at 06:51:31PM +0200, Sven Van Caekenberghe wrote: >>>> Hi Peter, >>>> >>>>> On 22 Jul 2017, at 14:12, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> this is a continuation of an older thread about quoting fields only when necessary. ( http://forum.world.st/NeoCSVWriter-automatic-quotes-td4924781.html ) >>>>> >>>>> I've attached fileouts of NeoCSV packages with the addition (I don't know if Metacello can file-out only changesets). >>>>> >>>>> The change doesn't affect the default behavior, only when explicitly requested. >>>>> >>>>> Peter >>>> >>>> I accepted your changes as such, the .mcz's were copied over to the main repositories. This is a pure & clean extension, so that is good. Thank you. >>>> >>>> This option is always going to be slower, but the current implementation might be improved, I think. >>>> >>>> The key test in #writeOptionalQuotedField: >>>> >>>> { >>>> lineEnd asString. >>>> separator asString. >>>> '"' } anySatisfy: [ :each | string includesSubstring: each ] >>>> >>>> will be quite slow. >>>> >>>> If we accept a little bit of (over safe) error on EOL and use any occurrence of CR or LF as needing a quote, we could switch to characters to test for. There exists a fast (primitive) test, #findFirstInString:inSet:startingAt: that can do all the testing in one go. If your version turns out to be slow, we could try that, if measurements show a difference. >>>> >>>> Regards, >>>> >>>> Sven >>>> >>>> >>> >> >> >

July 23, 2017

Re: [Pharo-users] Critical issues for Dr. Geo on P6

by Hilaire

I really find it hard to believe !! Le 22/07/2017 Ã 12:04, Stephane Ducasse a Ã©crit : > Yes but there are not concrete enough for me:) -- Dr. Geo http://drgeo.eu

July 23, 2017

Re: [Pharo-users] Why do we separate class/instance methods in the browser?

by Stephane Ducasse

Hi subbu I used the same metaphor :) Stef On Sat, Jul 22, 2017 at 4:37 PM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > On Saturday 22 July 2017 06:51 PM, Tim Mackinnon wrote: > >> The one that stuck out for me (and is actually mentioned in another >> thread this week) was the class/instance method difference. They >> conceptually understood the difference coming from other languages >> but our UI is tricky to understand with the Class button toggle we >> have, and if you get methods on the wrong side, like with a test, >> it's quite confusing. > > > It is an easy mistake to make and I have often seen this confusion in > beginners. With the attention on the methods panel and text input, it is > easy to overlook the class toggle button :-(. > > An easy fix is to switch background color to differentiate between class and > instance methods in both code and input panels. A better way would be to use > tabs (like in Inspector). > > BTW, I use the metaphor of toys (objects), moulds (classes) and mould > factory (metaclass). A mould is an object from the perspective of the mould > maker. Therefore operations on classes are 'methods' from the maker's > perspective (note the recursion!). > >> Anyway - this got me thinking - why do we bother having a toggle in >> our UI for this these days? Of course we know there is a class and a >> metaclass but given that we have icons for methods now (and also have >> a Protocol pane ) why don't we just show all the methods we have in >> one list and let you filter them or even see them all? It seems much >> easier and way more efficient to rapidly code this way. > > > This perspective comes from the traditional way - code and compile. In > Pharo, we code one method at a time and sources are held in an external file > and a pointer stored in each method, so displaying all methods in one panel > would result in multiple file reads. > >> The only question then would be how to create methods of the right >> type - whether to have a button to create the right template (and put >> the browser code pane in the right context) or whether to indicate >> it by convention of the method name when creating it like + new: >> aSize etc. (Or even: class new: aSize etc). >> >> The more I think about it, the more it seems like something we should >> consider trying both for making ourselves more efficient (I'll bet >> everyone has written a method on the wrong side by mistake) and also >> helping newcomers. > > > Such mistakes are part of the learning curve and decrease with time. > > Regards .. Subbu >

July 23, 2017

Re: [Pharo-users] NeoCSV change proposal

by Stephane Ducasse

thanks for the explanation. this is cool. On Sat, Jul 22, 2017 at 10:06 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 22 Jul 2017, at 21:51, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi peter >> Do you have an example that I understand? > > In its most simple form, CSV looks like this: > > a,b,c,d > > However, if a field is text, it might contain a comma itself, or other problematic characters like line endings, hence there is a provision for quoting fields, as follows: > > "a","b","c",d > > Now, "a" could be "a1,a2" and still be one field. Embedded quotes are doubled. > > Not all fields need quoting, normally only text or string fields. If you know something is an integer, you don't need quotes, like d above. > > Since CSV is normally a collection of identical records, you set these options for all of them. > > What Peter wanted, and now implemented himself as an option, is to make the quoting optional per field, per record, by first checking if a field contains dangerous characters and only then adding the quotes. I guess this makes most sense in the context of generating a CSV file for humans to edit. > >> @Svn Once the change is integrated could you add a little paragraph to >> the chapter? >> >> Stef >> >> On Sat, Jul 22, 2017 at 6:51 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> Hi Peter, >>> >>>> On 22 Jul 2017, at 14:12, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> this is a continuation of an older thread about quoting fields only when necessary. ( http://forum.world.st/NeoCSVWriter-automatic-quotes-td4924781.html ) >>>> >>>> I've attached fileouts of NeoCSV packages with the addition (I don't know if Metacello can file-out only changesets). >>>> >>>> The change doesn't affect the default behavior, only when explicitly requested. >>>> >>>> Peter >>> >>> I accepted your changes as such, the .mcz's were copied over to the main repositories. This is a pure & clean extension, so that is good. Thank you. >>> >>> This option is always going to be slower, but the current implementation might be improved, I think. >>> >>> The key test in #writeOptionalQuotedField: >>> >>> { >>> lineEnd asString. >>> separator asString. >>> '"' } anySatisfy: [ :each | string includesSubstring: each ] >>> >>> will be quite slow. >>> >>> If we accept a little bit of (over safe) error on EOL and use any occurrence of CR or LF as needing a quote, we could switch to characters to test for. There exists a fast (primitive) test, #findFirstInString:inSet:startingAt: that can do all the testing in one go. If your version turns out to be slow, we could try that, if measurements show a difference. >>> >>> Regards, >>> >>> Sven >>> >>> >> > >

July 23, 2017

Re: [Pharo-users] Is it possible to change the Pharo application title bar?

by kmo

DisplayScreen hostWindowTitle: 'your title' works on Windows and Mac (I think) but does NOT work on Linux. This is a sore point with me as I reported the bug (12231) ages ago and someone very kindly wrote a fix - but it was never applied because no one knew how to apply it!!! So the bug was closed. Note that you can set the title (even on Linux) with a command line option. This is buggy too - you cannot have a space in the title! (bug 18145) All in all, it doesn't reflect well on Pharo. I've just re-opened both these bugs - perhaps one day they'll be fixed. I'm not holding my breath. -- View this message in context: http://forum.world.st/Is-it-possible-to-change-the-Pharo-application-title-… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 23, 2017

Re: [Pharo-users] Is it possible to change the Pharo application title bar?

by Henrik Nergaard

DisplayScreen hostWindowTitle: 'NewTitle' Best regards, Henrik ________________________________ Fra: Pharo-users <pharo-users-bounces(a)lists.pharo.org> pÃ¥ vegne av Tim Mackinnon <tim(a)testit.works> Sendt: 22. juli 2017 18:44:46 Til: Pharo Users Newsgroup Emne: [Pharo-users] Is it possible to change the Pharo application title bar? Hi - is it possible to easily change the Pharo.image title bar in the pharo application? (As in the OSX title bar, or Windows one). I find that I often have multiple images running and its difficult to distinguish them - so having a title that had the immediate path of the image would be very useful. Iâd prefer not to have to rename image files (althoughI guess could if its not easy to change the title). Tim

July 23, 2017

Re: [Pharo-users] NeoCSV change proposal

by Peter Uhnak

Ah, ByteArrayMap, I was trying ByteArray. Not sure what the next step is here: should I add it and send you mczs, or will you do it yourself? (it is a simple change). Peter On Sat, Jul 22, 2017 at 10:51:42PM +0200, Sven Van Caekenberghe wrote: > Peter, > > > On 22 Jul 2017, at 22:27, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > > Hi Sven, > > > > my use case was hand-edited CSVs (therefore the quotes are extra clutter), which imples that I would be hand-viewing/editing only small CSVs (no performance issues). > > > > I agree that we should err on the safe side with CR & LF (e.g. tools may sometimes autoconvert line endings). > > > > Regarding performance: > > > > #findFirstInString:inSet:startingAt: didn't work for me (not sure if bug, or I don't know how to use), so I've trried with inCharacterSet: > > Yes, it is a bitch to use, the the version you used does not use the primitive. > > Try playing with this: > > s10 := 'a' repeat: 10. > s100 := 'a' repeat: 100. > > searchSet := ByteArray new: 256 withAll: 0. > ',"', String crlf do: [ :each | searchSet at: each asInteger + 1 put: 1 ]. > > searchSet := (CharacterSet newFrom: ',"', String crlf) byteArrayMap. > > [ ByteString findFirstInString: s10 inSet: searchSet startingAt: 1 ] bench. > "15,160,161 per second" > [ ByteString findFirstInString: s100 inSet: searchSet startingAt: 1 ] bench. > "8,219,081 per second" > > ByteString findFirstInString: ',"', String crlf inSet: searchSet startingAt: 1. > > Sven > > > Tested on worst-case scenario - strings don't contain tested symbols. > > > > s10 := 'a' repeat: 10. > > s100 := 'a' repeat: 100. > > > > [ {'"'. ','. String cr. String lf } anySatisfy: [ :each | s10 includesSubstring: each ] ] bench. "'1,200,046 per second'" > > [ {'"'. ','. String cr. String lf } anySatisfy: [ :each | s100 includesSubstring: each ] ] bench. "'495,482 per second'" > > > > [ s10 includesAny: { $,. $". Character cr. Character lf } ] bench. "'2,819,416 per second'" > > [ s100 includesAny: { $,. $". Character cr. Character lf } ] bench. "'2,200,668 per second'" > > > > [ ByteString findFirstInString: s10 inCharacterSet: ',"', String crlf startingAt: 1 ] bench. "'1,187,324 per second'" > > [ ByteString findFirstInString: s100 inCharacterSet: ',"', String crlf startingAt: 1 ] bench. "'165,526 per second'" > > > > > > #includesAny: seems to be the best by far. > > > > Storing the tested characters didn't improve it by much. > > > > Peter > > > > On Sat, Jul 22, 2017 at 06:51:31PM +0200, Sven Van Caekenberghe wrote: > >> Hi Peter, > >> > >>> On 22 Jul 2017, at 14:12, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >>> > >>> Hi, > >>> > >>> this is a continuation of an older thread about quoting fields only when necessary. ( http://forum.world.st/NeoCSVWriter-automatic-quotes-td4924781.html ) > >>> > >>> I've attached fileouts of NeoCSV packages with the addition (I don't know if Metacello can file-out only changesets). > >>> > >>> The change doesn't affect the default behavior, only when explicitly requested. > >>> > >>> Peter > >> > >> I accepted your changes as such, the .mcz's were copied over to the main repositories. This is a pure & clean extension, so that is good. Thank you. > >> > >> This option is always going to be slower, but the current implementation might be improved, I think. > >> > >> The key test in #writeOptionalQuotedField: > >> > >> { > >> lineEnd asString. > >> separator asString. > >> '"' } anySatisfy: [ :each | string includesSubstring: each ] > >> > >> will be quite slow. > >> > >> If we accept a little bit of (over safe) error on EOL and use any occurrence of CR or LF as needing a quote, we could switch to characters to test for. There exists a fast (primitive) test, #findFirstInString:inSet:startingAt: that can do all the testing in one go. If your version turns out to be slow, we could try that, if measurements show a difference. > >> > >> Regards, > >> > >> Sven > >> > >> > > > >

July 23, 2017

Re: [Pharo-users] Pharo based system monitoring (Nagios like)?

by Norbert Hartl

Hi, I just made it nagios compatible. I developed it because I'm using munin [1]. You can look at this [2] blog post how to do it. If you have questions just ask. Norbert [1] http://munin-monitoring.org/ [2] http://norbert.hartl.name/blog/2015/05/16/system-monitoring-for-pharo-image… > Am 22.07.2017 um 19:41 schrieb Alistair Grant <akgrant0710(a)gmail.com>: > > Hi Everyone, > > Does anyone know of a system monitoring library written in Pharo (or at > least smalltalk)? > > I'm looking for something that provides functionality similar to nagios > and will allow me to monitor the basics, e.g. free disk space, cpu > usage, process presence, etc. > > I found Norbert Hartl's Monitoring library, but that looks like it acts > as an agent for nagios or similar. > > Thanks, > Alistair

July 22, 2017