February 2019 - Pharo-users

Re: [Pharo-users] Interval form: x to: y when x > y - or how to count down...

by Offray Vladimir Luna CÃ¡rdenas

On 22/2/19 16:57, Sven Van Caekenberghe wrote: > >> On 22 Feb 2019, at 22:35, Tim Mackinnon <tim(a)testit.works> wrote: >> >> If itâs always been that way - and things rely on it, sure. >> >> But it doesnât feel like the Smalltalk way to me. >> >> Having to know about adding -1 seems very C, whereas Smalltalk always seems more natural ... and 5 to: 1 seems like you would count down, not be an empty range and do nothing. >> >> But as you say, itâs personal. Iâm still curious though. > I personally would find it cool if > > 10 to: 1 > > counted down, it feels natural. But I must say I haven't thought it through. > > I do known that Interval is a class that leads to lots of discussions and disagreements. > I agree with Tim and Sven: "bigger to: smaller" should count backwards, if we think in the way we used on a day to day expectation. Cheers, Offray

Feb. 23, 2019

Re: [Pharo-users] JSON keys not quoted?

by Ben Coman

Just curiousity... Is an idempotent round trip required/expected ? cheers -ben On Sat, 23 Feb 2019 at 05:24, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Good catch. > > Indeed, JSON keys have to be strings. > > The question is, should the writer convert them for you, or should you > simply not use them ? > > I mean, there are many Pharo constructs that cannot be converted to JSON. > > Some could be output to JSON, but you won't be able to read them back in. > > So, if conversion would happen, the dictionary with integer keys will be > read back with strings keys. > > In STON, keys can be anything, even complex objects, like in Pharo itself. > > What will you do with { (1@2)->100 } asDictionary in JSON ? > > I have to think about this. > > > On 22 Feb 2019, at 21:21, Esteban Maringolo <emaringolo(a)gmail.com> > wrote: > > > > If you convert a Dictionary with numbers as keys it will produce not > > valid JSON [1], since all object keys must be quoted. > > > > E.g. > > NeoJSONWriter toString: (Dictionary with: 1->'foo'). > > or > > (Dictionary with: 1->'foo') asJson > > > > Should the library generate quoted keys? > > > > Seaside's WAJsonCanvas is manual, so it is up to the developer to > > render the object properly, but NeoJSON does it automatically. > > > > In Javascript this will throw a syntax error: > >> JSON.parse('{1: "foo"}') > > > > And this would generate a quoted key when serialized: > >> JSON.stringify({1: "foo"}) > >> {"1": "foo"} > > > > So my question is: should the library quote whatever you put as key in > > order to produce valid JSON syntax? [2] > > > > Regards. > > > > [1] https://jsonlint.com/ > > [2] > https://www.ecma-international.org/publications/standards/Ecma-404.htm > > > > Esteban A. Maringolo > > > > >

Feb. 23, 2019

Re: [Pharo-users] JSON keys not quoted?

by Sven Van Caekenberghe

> On 22 Feb 2019, at 22:52, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > El vie., 22 feb. 2019 a las 18:24, Sven Van Caekenberghe > (<sven(a)stfx.eu>) escribiÃ³: >> >> Good catch. >> >> Indeed, JSON keys have to be strings. >> >> The question is, should the writer convert them for you, or should you simply not use them ? >> >> I mean, there are many Pharo constructs that cannot be converted to JSON. >> >> Some could be output to JSON, but you won't be able to read them back in. >> So, if conversion would happen, the dictionary with integer keys will be read back with strings keys. > > This is the same as with any object, you can serialize any object to a > JSON object ({"foo": "baz"...}), but you can't read it back UNLESS you > know exactly what to convert it to. > > Maybe there should be an "integer" mapping that converts the number in > string representation back to an Integer when deserializing it. > > >> In STON, keys can be anything, even complex objects, like in Pharo itself. > > That's why STON is better. :) > > >> What will you do with { (1@2)->100 } asDictionary in JSON ? > > That is not valid JSON and not even JS. I mean, AFAIU in JS properties > are also strings, even array indices. > > Try to do this: >> JSON.stringify({{x: 1, y: 2}: 100}) > > And it will fail. > > E.g. >> point = {x: 1, y: 2}; >> object = {point: 100} >> object > < {point: 100} > > There the "point" is a literal, not a variable reference. > > But if instead you do >> point = {x: 1, y: 2}; >> object = {}. >> object[point] = 100; >> object > < {[object Object]: 100} > > you get a frankenstein because the key got converted to a string: > >> Object.keys(obj) > < ["[object Object]"] > > The issue here is that the JSON writer creates invalid JSON syntax. > So it's either JSON (valid) or it's something else. OK, that is a very good point. So you if it gave an error that would be good too ? > Not that I'm a fan of this, but I got bitten when submitting a > document to CouchDB which got rejected because of this invalid syntax. > > To make things worse: >> object = {1: 'foo'} >> object[1] > < "foo" >> object["1"] > < "foo" > > WAT! [1] > > >> I have to think about this. > > Food for thought for the weekend. > > > Regards, > > > > [1] https://www.destroyallsoftware.com/talks/wat > > Esteban A. Maringolo

Feb. 22, 2019

Re: [Pharo-users] Interval form: x to: y when x > y - or how to count down...

by Sven Van Caekenberghe

> On 22 Feb 2019, at 22:35, Tim Mackinnon <tim(a)testit.works> wrote: > > If itâs always been that way - and things rely on it, sure. > > But it doesnât feel like the Smalltalk way to me. > > Having to know about adding -1 seems very C, whereas Smalltalk always seems more natural ... and 5 to: 1 seems like you would count down, not be an empty range and do nothing. > > But as you say, itâs personal. Iâm still curious though. I personally would find it cool if 10 to: 1 counted down, it feels natural. But I must say I haven't thought it through. I do known that Interval is a class that leads to lots of discussions and disagreements. > Tim > > Sent from my iPhone > >> On 22 Feb 2019, at 16:13, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: >> >>> On 22/02/2019 15:57, Tim Mackinnon wrote: >>> I've just been caught out with Intervals - why can't you do: >>> 5 to: 1 do: [ :i | Transcript show: i printString] (eg a negative interval)? >>> >>> if you want to iterate down a series of numbers do you really have to do: >>> 5 to: 1 by: -1 do: [â¦ >>> >>> I always assumed that if x > y the step was automatically -1 (but its not). >> >> Expectations are obviously personal, but as far as I am concerned, I'd expect to see the behavior that Pharo implements. If you don't specify by:, you get a default value of 1. That's much simpler than a default value depending on the bounds of the interval. >> >> Konrad. >> >> > >

Feb. 22, 2019

Re: [Pharo-users] JSON keys not quoted?

by Esteban Maringolo

El vie., 22 feb. 2019 a las 18:24, Sven Van Caekenberghe (<sven(a)stfx.eu>) escribiÃ³: > > Good catch. > > Indeed, JSON keys have to be strings. > > The question is, should the writer convert them for you, or should you simply not use them ? > > I mean, there are many Pharo constructs that cannot be converted to JSON. > > Some could be output to JSON, but you won't be able to read them back in. > So, if conversion would happen, the dictionary with integer keys will be read back with strings keys. This is the same as with any object, you can serialize any object to a JSON object ({"foo": "baz"...}), but you can't read it back UNLESS you know exactly what to convert it to. Maybe there should be an "integer" mapping that converts the number in string representation back to an Integer when deserializing it. > In STON, keys can be anything, even complex objects, like in Pharo itself. That's why STON is better. :) > What will you do with { (1@2)->100 } asDictionary in JSON ? That is not valid JSON and not even JS. I mean, AFAIU in JS properties are also strings, even array indices. Try to do this: > JSON.stringify({{x: 1, y: 2}: 100}) And it will fail. E.g. > point = {x: 1, y: 2}; > object = {point: 100} > object < {point: 100} There the "point" is a literal, not a variable reference. But if instead you do > point = {x: 1, y: 2}; > object = {}. > object[point] = 100; > object < {[object Object]: 100} you get a frankenstein because the key got converted to a string: > Object.keys(obj) < ["[object Object]"] The issue here is that the JSON writer creates invalid JSON syntax. So it's either JSON (valid) or it's something else. Not that I'm a fan of this, but I got bitten when submitting a document to CouchDB which got rejected because of this invalid syntax. To make things worse: > object = {1: 'foo'} > object[1] < "foo" > object["1"] < "foo" WAT! [1] > I have to think about this. Food for thought for the weekend. Regards, [1] https://www.destroyallsoftware.com/talks/wat Esteban A. Maringolo

Feb. 22, 2019

Re: [Pharo-users] Interval form: x to: y when x > y - or how to count down...

by Tim Mackinnon

If itâs always been that way - and things rely on it, sure. But it doesnât feel like the Smalltalk way to me. Having to know about adding -1 seems very C, whereas Smalltalk always seems more natural ... and 5 to: 1 seems like you would count down, not be an empty range and do nothing. But as you say, itâs personal. Iâm still curious though. Tim Sent from my iPhone > On 22 Feb 2019, at 16:13, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > >> On 22/02/2019 15:57, Tim Mackinnon wrote: >> I've just been caught out with Intervals - why can't you do: >> 5 to: 1 do: [ :i | Transcript show: i printString] (eg a negative interval)? >> >> if you want to iterate down a series of numbers do you really have to do: >> 5 to: 1 by: -1 do: [â¦ >> >> I always assumed that if x > y the step was automatically -1 (but its not). > > Expectations are obviously personal, but as far as I am concerned, I'd expect to see the behavior that Pharo implements. If you don't specify by:, you get a default value of 1. That's much simpler than a default value depending on the bounds of the interval. > > Konrad. > >

Feb. 22, 2019

Re: [Pharo-users] JSON keys not quoted?

by Sven Van Caekenberghe

Good catch. Indeed, JSON keys have to be strings. The question is, should the writer convert them for you, or should you simply not use them ? I mean, there are many Pharo constructs that cannot be converted to JSON. Some could be output to JSON, but you won't be able to read them back in. So, if conversion would happen, the dictionary with integer keys will be read back with strings keys. In STON, keys can be anything, even complex objects, like in Pharo itself. What will you do with { (1@2)->100 } asDictionary in JSON ? I have to think about this. > On 22 Feb 2019, at 21:21, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > If you convert a Dictionary with numbers as keys it will produce not > valid JSON [1], since all object keys must be quoted. > > E.g. > NeoJSONWriter toString: (Dictionary with: 1->'foo'). > or > (Dictionary with: 1->'foo') asJson > > Should the library generate quoted keys? > > Seaside's WAJsonCanvas is manual, so it is up to the developer to > render the object properly, but NeoJSON does it automatically. > > In Javascript this will throw a syntax error: >> JSON.parse('{1: "foo"}') > > And this would generate a quoted key when serialized: >> JSON.stringify({1: "foo"}) >> {"1": "foo"} > > So my question is: should the library quote whatever you put as key in > order to produce valid JSON syntax? [2] > > Regards. > > [1] https://jsonlint.com/ > [2] https://www.ecma-international.org/publications/standards/Ecma-404.htm > > Esteban A. Maringolo >

Feb. 22, 2019

JSON keys not quoted?

by Esteban Maringolo

If you convert a Dictionary with numbers as keys it will produce not valid JSON [1], since all object keys must be quoted. E.g. NeoJSONWriter toString: (Dictionary with: 1->'foo'). or (Dictionary with: 1->'foo') asJson Should the library generate quoted keys? Seaside's WAJsonCanvas is manual, so it is up to the developer to render the object properly, but NeoJSON does it automatically. In Javascript this will throw a syntax error: > JSON.parse('{1: "foo"}') And this would generate a quoted key when serialized: > JSON.stringify({1: "foo"}) > {"1": "foo"} So my question is: should the library quote whatever you put as key in order to produce valid JSON syntax? [2] Regards. [1] https://jsonlint.com/ [2] https://www.ecma-international.org/publications/standards/Ecma-404.htm Esteban A. Maringolo

Feb. 22, 2019

Re: [Pharo-users] firebase client in pharo?

by Esteban Maringolo

Not that I know, I'm working on a CouchDB client to have something close to what Firebase, or even better, Firestore can provide. There is a thread about it. Esteban A. Maringolo El vie., 22 feb. 2019 a las 15:37, Tudor Girba (<tudor(a)tudorgirba.com>) escribiÃ³: > > Hi, > > Did anyone worked on connecting Pharo with Firebase? > > Cheers, > Doru > > > -- > www.feenk.com > > "Quality cannot be an afterthought." > >

Feb. 22, 2019

firebase client in pharo?

by Tudor Girba

Hi, Did anyone worked on connecting Pharo with Firebase? Cheers, Doru -- www.feenk.com "Quality cannot be an afterthought."

Feb. 22, 2019

How to test a new Iceberg baseline?

by Tim Mackinnon

How does one go about testing an Iceberg/metacello baseline? Two parts to this actually - I want to check one under my control - and am wondering if there is a lint checker or some way to tell me what it will load (without having to check it in and try. Or if you do this - can you test loading from a branch? Similarly - if I want to try improving a baseline in another project - is there an easy way to do this (in this case, I canât really check it in - or I suppose I can fork all the dependencies and put them all in branches - but then how do convince each part of the chain to load from my forkâ¦ this sounds like a world of pain). So any tips? Tim

Feb. 22, 2019

Re: [Pharo-users] Interval form: x to: y when x > y - or how to count down...

by Konrad Hinsen

On 22/02/2019 15:57, Tim Mackinnon wrote: > I've just been caught out with Intervals - why can't you do: > 5 to: 1 do: [ :i | Transcript show: i printString] (eg a negative interval)? > > if you want to iterate down a series of numbers do you really have to do: > 5 to: 1 by: -1 do: [â¦ > > I always assumed that if x > y the step was automatically -1 (but its not). Expectations are obviously personal, but as far as I am concerned, I'd expect to see the behavior that Pharo implements. If you don't specify by:, you get a default value of 1. That's much simpler than a default value depending on the bounds of the interval. Konrad.

Feb. 22, 2019

Interval form: x to: y when x > y - or how to count down...

by Tim Mackinnon

I've just been caught out with Intervals - why can't you do: 5 to: 1 do: [ :i | Transcript show: i printString] (eg a negative interval)? if you want to iterate down a series of numbers do you really have to do: 5 to: 1 by: -1 do: [â¦ I always assumed that if x > y the step was automatically -1 (but its not). I asked on Discord - and someone pointed out that if you use variables it could be ambiguous - but is it really? I donât know if other smalltalks do it this way (I vaguely recall Dolphin going down, but not sure). Either way the Interval comment should mention this - and Iâll correct it when I get the wisdom of the crowd here. Tim

Feb. 22, 2019

What does the Package and Sub-Package comment do?

by Tim Mackinnon

Hi - I notice that you can sort of put comments on packages - but Iâm not sure if this is working or if its supposed to work? When I type something it seems to create and extra Manifest tag, and then the comment that I type seems to be the same for the package and all of its sub tags? Is this a work in progress? Should Calypso even show a comment for the tags (or is it read only for them - as its the parent). Iâm just not clear on what it does, and whether I can programmatically add stuff to it or not? (I was thinking for exercism to store exercise information there - but maybe I will stick to the test class comment) Tim

Feb. 22, 2019

Re: [Pharo-users] Embedding object properties in NeoJSON mappings

by Esteban Maringolo

Hi, El vie., 22 feb. 2019 a las 7:55, Sven Van Caekenberghe (<sven(a)stfx.eu>) escribiÃ³: > > On 22 Feb 2019, at 02:05, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > Am I stretching it too much? :) > > Yes, this is out of the scope of NeoJSON. > > As you know, JSON is strictly limited and kept simple, by design. > Things people do to shoehorn objects, classes, types, ids, collections, references, etc on to it are exactly that, hacks on top. > There are many ways to try to do any of this. I though so. :) > What you are doing now, a two pass approach, is what I would do too: first use NeoJSON > to get a standard structure (maybe use NeoJSONObject for simplicity), > next do some extra work - and vice versa. > Note that Pharo itself might lack some meta info to describe a mapping by itself > (collections have no element types for example), so a good mapping is always > necessary to go to a statically typed model. > > There is a reason STON exists, it is one answer to this problem. Thanks, I'll look into it to see if I can adapt it to my needs. Regards,

Feb. 22, 2019

Re: [Pharo-users] Pharo Object Serialization

by BrunoBB

Peter, Yes i already read those posts. Maybe i will try and see but i highly doubt i will use it in production. Back in the old days i used it a lot with Dolphin Smalltalk, David Jorisek provided good support then. regards, bruno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 22, 2019

Re: [Pharo-users] Streams for FileReference in Pharo 7

by Sven Van Caekenberghe

https://github.com/pharo-project/pharo/pull/2695 > On 18 Feb 2019, at 16:52, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > OK, I that is what I expected. > I will study this again and make a PR with better comments and tests. > >> On 18 Feb 2019, at 16:32, ducasse <stepharo(a)netcourrier.com> wrote: >> >>> >>> >>> I have been thinking a bit more about this, and I have a lot of problems with >>> >>> Integer>>#putOn: aStream >>> aStream isBinary >>> ifTrue: [ self asByteArray do: [ :each | aStream nextPut: each ] ] >>> ifFalse: [ self asString putOn: aStream ] >>> >>> I think we should simply remove this method. It is ugly and wrong. >> >> I agree >> >>> #<< should simply be a shortcut for either #nextPut: and #nextPutAll: and nothing more. >>> >>> The following two are OK for me: >>> >>> String streamContents: [ :out | out << 'Hello' << $! ]. >>> ByteArray streamContents: [ :out | out << #[ 1 2 3 ] << 4 ]. >>> >>> But the following most definitively not: >>> >>> (ByteArray streamContents: [ :out | out << 16rFF << 16rFF11 << 16rFFFF22 << 16rFFFFFF33 ]) hex. >>> >>> When you write out an integer, you have to decide its size, that can never depend on the magnitude (because there is no way to read this back unless there is additional bracketing). >>> >>> Also, printing to a stream should be (very) efficient. Making copies of objects just for conversion purposes should be avoided. >> >> yes. >> >>> >>> I think that if we remove Integer>>#putOn: I could live with >>> >>> ZnEncodedStream>>#<< anObject >>> anObject putOn: self >> >> Yes :) >> and remove the ugly one? Yes >> >>> >>> The other solution is to define #<< as strictly the same as #nextPutAll: and remove all #putOn: implementors. >>> >>> Sven >

Feb. 22, 2019

Re: [Pharo-users] Pharo Object Serialization

by PBKResearch

Bruno OmniBase was ported to Pharo 6+ in Jun 2018. The original porting work was done by Esteban Lorenzano, but he pointed out that, as a non-user, he is not in a position to provide any support. It was used to a small extent by me, and much more by Matias Maretto. The repo is at https://github.com/estebanlm/OmniBase. There were a couple of tweaks needed to get it fully working; I don't know whether they were incorporated in the repo version. I haven't really used it much - my project got overtaken by other work. I think Matias used it more. You can see the whole story if you search for the subject 'OmniBase for Pharo 6' in this forum. HTH Peter Kenny -----Original Message----- From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of BrunoBB Sent: 22 February 2019 03:05 To: pharo-users(a)lists.pharo.org Subject: [Pharo-users] Pharo Object Serialization Hi, Which are the options for serialize objects in Pharo ? I know there is Fuel (https://rmod.inria.fr/web/software/Fuel) OmniBase is not supported any more. OmniBase was pretty cool even transactional !!! What are you using ? (of course there is GemStone/S but i was not able to convince my client yet :) regards, bruno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 22, 2019

Iliad & disbled JS

by Siemen Baader

Hi, has support for disabled JavaScript been removed from Iliad? When I do $ curl http://localhost:9999/examples/counters I get [...] <h1>0</h1><a href="javascript:{}" onclick="iliad.evaluateAction("/examples/counters?_session=e333771f-db3e-0d00-bc9a-e623066cc382&_action=10073&_state=bb37771f");">++</a> [...] So it works only with JS enabled. It would be nice to be able to make requests from non-JS-capable clients such as ZnEasy for testing purposes. Can I re-enable it? -- Siemen

Feb. 22, 2019

Re: [Pharo-users] Embedding object properties in NeoJSON mappings

by Sven Van Caekenberghe

Hi, > On 22 Feb 2019, at 02:05, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > Hi all (again), > > As part of writing the port (and adaptation to use Zinc and NeoJSON), > a CouchDB JSON-REST API, now I find something I don't know how to > solve using NeoJSON mappings. > > All objects you store in CouchDB at a particular URI are saved as > "Documents", so if you save a dictionary with keys "name", "height", > "c" to "/people/1234" , when you query "people/1234" you get the keys > of the saved dictionary PLUS to extra keys called _id and _rev. > > Then when you query (GET) back the document you get a JSON like this: > {"_id": ..., "_rev": ..., "name": ..., "height":...,} > > My Idea is that I can wrap any object serializable as JSON within > aDocument, but then if I define CouchDocument class>>#neoJsonMapping: > mapper as: > > mapper for: self do: [ :mapping | > mapping mapAccessor: #id to: '_id'. > mapping mapAccessor: #revision to: '_rev'. > mapping mapAccessor: #class to: '_class' > ]. > > I have no way to "flatten"/"merge" anObject within aDocument. > > I would expect something like > > mapper for: self do: [ :mapping | > mapping mapAccessor: #id to: '_id'. > mapping mapAccessor: #revision to: '_rev'. > mapping mapAccessor: #class to: '_class' > mapping embed: [:object | object whatToEmbed] > ]. > > Of course this is awkward, because if I need to read it back, the > "extraction" of the embeded properties needs to know which belongs to > which and more importantly , what to instantiate! > > Of course I can do it manually without using NeoJSON (It's already > being done [1]) , but I like when different libraries things fit > naturally together :) > > > Am I stretching it too much? :) Yes, this is out of the scope of NeoJSON. As you know, JSON is strictly limited and kept simple, by design. Things people do to shoehorn objects, classes, types, ids, collections, references, etc on to it are exactly that, hacks on top. There are many ways to try to do any of this. What you are doing now, a two pass approach, is what I would do too: first use NeoJSON to get a standard structure (maybe use NeoJSONObject for simplicity), next do some extra work - and vice versa. Note that Pharo itself might lack some meta info to describe a mapping by itself (collections have no element types for example), so a good mapping is always necessary to go to a statically typed model. There is a reason STON exists, it is one answer to this problem. Sven > Regards, > > > [1] Currently the writing is done manually and the refresh (which is > also a GET) does the following: > > CouchDocument>>#refresh > " Update this Document to the latest revision " > | response | > response := self information. "response is a Dictionary" > revision := response at: '_rev'. > object := response couchToObject. > ^response > > And here happens the magic, it searchs for a "_class" key which if > present will use to instantiate the object "wrapped" by the document. > > Dictionary>>couchToObject > | class object | > self removeKey: '_id' ifAbsent: []. > self removeKey: '_rev' ifAbsent: []. > self keysAndValuesDo: [:key :value | self at: key put: value couchToObject]. > class := (self at: '_class' ifAbsent: [^self]) asSymbol asClass. > object := class basicNew. > object jsonInstanceVariableNames keysAndValuesDo: [:index :key | > self at: key ifPresent: [:value | object instVarAt: index put: value]]. > ^object > > #jsonInstanceVariableNames is another level of "mapping" here, that > defined what to map from the Document response. > > > Esteban A. Maringolo >

Feb. 22, 2019

Remember to registrar to Pharo days 2019!

by Esteban Lorenzano

Dear all, Pharo days registration is open since two weeks now, and we are starting to work on the schedule and organising the social event :) Register now! Pharo days is a gathering of the Pharo community to exchange, discuss and code with your online colleagues. Join us to share your experiences and help to make a better Pharo! To register, please proceed to the Pharo Days 2019 web page: https://pharo.org/2019PharoDays <https://pharo.org/2019PharoDays>, or go directly to the association event: https://association.pharo.org/event-3255426 <https://association.pharo.org/event-3255426>. (Yes, the schedule is still to be defined, stay tuned). If there are any questions or problems, I am happy to answer them. Esteban

Feb. 22, 2019

Re: [Pharo-users] im using pharo 7 with linux env. but cannot input korean.

by Hilaire

Thanks Pierce. So kind of work out of the box as long as the appropriate font is selected. Hilaire Le 22/02/2019 Ã 04:34, Pierce Ng a Ã©critÂ : > Hi Hilaire, > > My self-built VM on Windows 7 doesn't have the option either. But, > multilingual input into Pharo works. > > Outside of Pharo, configure Windows multilingual input. Within Pharo, > choose a font like Arial Unicode MS. Then just switch Windows input > system using hot-key or mouse click, and type. See screenshot. > > Pierce -- Dr. Geo http://drgeo.eu

Feb. 22, 2019

Re: [Pharo-users] Partition/Sync ready databases for Pharo?

by Pierce Ng

On Tue, Feb 19, 2019 at 01:02:51PM +0000, Tim Mackinnon wrote: > When you say Fossil - are you referring to > "https://fossil-scm.org/index.html/doc/trunk/www/index.wikiâ ? > Iâve seen it come up a few times - is it good? Yes I mean the Fossil SCM. I use it as a personal wiki and file repo. It comes with built-in ticketing system and forum, all wrapped into one executable file. Fossil also imports/exports Git repos. I'd use Fossil for small development teams too. Except for game development and other cases involving multi-GB repos with lots of binary blobs. > can you hook into it to save application runtime artefacts such that a > distributed application can read them back Fossil was designed as a standalone executable. It is difficult to "library-ify" and the developers have no plan to do so. But it is just a single executable, supports JSON output for some of its functions, and can be invoked via OSSubprocess and the like, conceptually similar to how Iceberg uses libgit2 to do Git stuff. Pierce

Feb. 22, 2019

Re: [Pharo-users] Partition/Sync ready databases for Pharo?

by Pierce Ng

On Tue, Feb 19, 2019 at 10:36:18AM -0300, Esteban Maringolo wrote: > No problem, I was going to ask about Fossil as well, I know it is a > self contained SCM, with issue tracker, and whatnot. People that uses > it don't want to use git except if forced to. > So I also ask how this would work. :) Fossil's built-in sync mechanism is described at https://fossil-scm.org/index.html/doc/trunk/www/sync.wiki. Fossil's traffic works through tunneling - this is how I 'fossil push' new blog posts from my laptop to my server through an SSH tunnel. I had also tested Fossil behind Internet-reachable Caddy HTTPS reverse proxy, which works too. For your use case, I might approach it like this: Write data locally and commit to Fossil as blobs. To sync, run Fossil under OSSubprocess to sync with the central server, either directly (if Fossil on central server is directly reachable) or thru a tunnel created by your application if your application runs on both ends. > I saw SQLite-sync before, but it is a commercial product, and its > platform support/setup seems convoluted. > > dqlite might be a viable alternative, from more than reliable > provider, it's is not clear whether I have to use a different library > to access SQLite (it seems so) or a special wire protocol/api calls. I was actually thinking of https://github.com/rqlite/rqlite/ but did not remember the name when I replied originally. But it seems that, however you choose to sync, your application still needs to handle any data conflict that arises. Pierce

Feb. 22, 2019

Re: [Pharo-users] Running pharo in daemon mode

by Pierce Ng

On Tue, Feb 19, 2019 at 05:17:34AM -0800, sergio ruiz wrote: > My daemontools run file looks like: > but for some reason, it just sits and grinds and restarts.. never remaining > started for more than a second.. PharoDebug.log or "ps ax | egrep readproctitle" should contain some clues. > VM="/home/bandtracker/pharoImages/pharo" > IMAGE="/home/bandtracker/pharoImages/Pharo.image" Looks like you put the VM and image/changes files in the same directory. Depending on how you set up, Pharo may need write-access to the image's containing directory, /home/bandtracker/pharoImages in your case. I suggest to put the VM files somewhere else, and owned by root:root. This greatly reduces the risk of bug or exploited vulnerability in your code or Pharo running as your uid overwriting the VM files. Pierce

Feb. 22, 2019