Re: [Pharo-users] voyage mongo and transactionality

[PBKResearch]

It may be irrelevant, but I have been playing recently with OmniBase, which is 
a fully object-oriented database system, now over 20 years old, but it still 
works very well for my uses. David Gorišek, the author, claims that it has ACID 
properties. From my reading, updates operate on a proxy object, which is not 
written to the database until an explicit commit is given. A second transaction 
accessing the same object will still see the original until the change is 
committed. What happens to a proxy which is never committed is not clear, but 
if Gorišek is right, the stored data can never be contaminated. I think a proxy 
in this sense is equivalent to a memento.

 

Thanks to Esteban Lorenzano, OmniBase is now available on Pharo. The code is 
ancient, there is no documentation and obviously no support, but it might be 
worth while for someone to try some software archaeology and put it to use. I 
have found it possible to create and maintain a small database of natural 
language information, and access is fairly quick and easy – and it’s all 
Smalltalk.

It claims to store all kinds of Smalltalk objects, except block closures, and 
skimming through the code it seems to incorporate a serializer similar to Fuel.

 

The only documentation I have found is a slideshow at 
https://www.slideshare.net/esug/omni-baseobjectdatabase. I have found out a few 
things about it, if anyone is interested.

 

Peter Kenny

 

 

From: Pharo-users  On Behalf Of Norbert 
Hartl
Sent: 09 October 2019 18:08
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] voyage mongo and transactionality

 

 


Am 09.10.2019 um 16:48 schrieb "jtuc...@objektfabrik.de 
 " mailto:jtuc...@objektfabrik.de> >:

 

This is a tricky mine field. Sometimes you need a lot of business functionality 
in objects referenced in your objects that are currently in the editor. So I'm 
still to see a project in which the memento pattern really worked for more 
complex scenarios. How deep do you dive to have enough memento objects to 
provide the functionality needed. I guess you can do that with some sort of 
object-level transaction framework that automatically creates mementos of 
whatever object is being navigated to during some kind of processing-context. I 
guess slots could be of use here. But this is not trivial for general cases.

 

Yes it is tricky. You can have copies of business objects but you have always 
references to the business objects not pointing to the copy. 

And you need to know which objects should be tracked. In Gemstone IIRC it is 
easy as it is the time the object is copied from the stone to the gem it is 
registered in the current transaction. So you can check it and committing if it 
changed because you have to write it back. The important point here might be 
get noticed when a reference is acquired. In pharo it is not that easy but 
could be done if object would be reified and interceptable. 

In my experience, this problem area makes for the other 70% of the time spent 
on developing GUI or Web applications, besides the 60% for GUI design and 
implementation and 25% business logic...

70% + 60% + 25% + 30% = 185%

 

sounds indeed very realistic if it comes to project planning. There is even a 
rule saying that for the first 90% of the project you need the first 90% of 
time and for the last 10% of the project you need the second 90% of time. 



I'd be interested to learn about patterns to handle such more complex things. 
We constantly travel back and forth between implementing stuff in the GUI 
handlers (copying values to the GUI classes that access themselves during GUI 
operations and push values to the business objects when the users clicks on 
OK), using mementos (which most of the times are nets of mementos that are 
created manually - "we know what we'll touch in this Editor") and operating on 
business objects directly and relying on the persistence mechanism (Glorp in 
our case) and its rollback behaviour. All three have lots of weaknesses and 
seem to have their place nevertheless.

So this is a very interesting discussion and I think this is an area that has 
not been solved yet.

I think it isn‘t solved and I find every piece of information about it very 
interesting.

 

Norbert



Joachim

 

 

 

 

 

 

Am 09.10.19 um 16:25 schrieb James Foster:

Thanks for the explanation. And, yes, this is an artifact of your design; if 
you put intermediate values into domain objects then they will remain in your 
domain objects to be seen later. From what you’ve described, I don’t see how it 
would be any different in a non-image environment (Java, C#, etc.), unless you 
re-read the entire object graph from the database. As someone else mentioned, 
this would be a good place for the Memento Pattern. 

 

James





On Oct 9, 2019, at 1:59 AM, Jonathan van Alteren mailto:jvalte...@objectguild.com> > wrote:

 

Hi James, 

 

I see how my explanation might be unclear.

 

Re: [Pharo-users] voyage mongo and transactionality

[Norbert Hartl]

> Am 09.10.2019 um 16:48 schrieb "jtuc...@objektfabrik.de" 
> :
> 
> 
> This is a tricky mine field. Sometimes you need a lot of business 
> functionality in objects referenced in your objects that are currently in the 
> editor. So I'm still to see a project in which the memento pattern really 
> worked for more complex scenarios. How deep do you dive to have enough 
> memento objects to provide the functionality needed. I guess you can do that 
> with some sort of object-level transaction framework that automatically 
> creates mementos of whatever object is being navigated to during some kind of 
> processing-context. I guess slots could be of use here. But this is not 
> trivial for general cases.

Yes it is tricky. You can have copies of business objects but you have always 
references to the business objects not pointing to the copy. 
And you need to know which objects should be tracked. In Gemstone IIRC it is 
easy as it is the time the object is copied from the stone to the gem it is 
registered in the current transaction. So you can check it and committing if it 
changed because you have to write it back. The important point here might be 
get noticed when a reference is acquired. In pharo it is not that easy but 
could be done if object would be reified and interceptable. 
> In my experience, this problem area makes for the other 70% of the time spent 
> on developing GUI or Web applications, besides the 60% for GUI design and 
> implementation and 25% business logic...
> 
70% + 60% + 25% + 30% = 185%

sounds indeed very realistic if it comes to project planning. There is even a 
rule saying that for the first 90% of the project you need the first 90% of 
time and for the last 10% of the project you need the second 90% of time. 
> I'd be interested to learn about patterns to handle such more complex things. 
> We constantly travel back and forth between implementing stuff in the GUI 
> handlers (copying values to the GUI classes that access themselves during GUI 
> operations and push values to the business objects when the users clicks on 
> OK), using mementos (which most of the times are nets of mementos that are 
> created manually - "we know what we'll touch in this Editor") and operating 
> on business objects directly and relying on the persistence mechanism (Glorp 
> in our case) and its rollback   behaviour. All three have lots of 
> weaknesses and seem to have their place nevertheless.
> 
> So this is a very interesting discussion and I think this is an area that has 
> not been solved yet.
> 
I think it isn‘t solved and I find every piece of information about it very 
interesting.

Norbert
> Joachim
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> Am 09.10.19 um 16:25 schrieb James Foster:
>> Thanks for the explanation. And, yes, this is an artifact of your design; if 
>> you put intermediate values into domain objects then they will remain in 
>> your domain objects to be seen later. From what you’ve described, I don’t 
>> see how it would be any different in a non-image environment (Java, C#, 
>> etc.), unless you re-read the entire object graph from the database. As 
>> someone else mentioned, this would be a good place for the Memento Pattern.
>> 
>> James
>> 
>>> On Oct 9, 2019, at 1:59 AM, Jonathan van Alteren 
>>>  wrote:
>>> 
>>> Hi James,
>>> 
>>> I see how my explanation might be unclear.
>>> 
>>> We have a main form for the agenda and a subform for an item, which is 
>>> shown using Seaside call/answer. The save button of the subform is clicked, 
>>> which adds the item to the underlying agenda model object, but the save 
>>> button of the main form is not clicked by the user. The callback for the 
>>> main save button sends the save message to the agenda object, causing the 
>>> database to be updated.
>>> 
>>> So yes, the browser does submit the data on the subform, it's the main form 
>>> component that doesn't receive the save button callback. I realize that 
>>> this is in large part an issue with our design. However, the way object 
>>> persistence seems to work in the image environment plays a large role. 
>>> 
>>> 
>>> Kind regards,
>>> 
>>> Jonathan van Alteren
>>> 
>>> Founding Member | Object Guild
>>> jvalte...@objectguild.com
 On 8 Oct 2019, 15:41 +0200, James Foster , wrote:
 
> On Oct 8, 2019, at 3:05 AM, Jonathan van Alteren 
>  wrote:
> 
> We've encountered an issue where a user makes changes to an agenda, but 
> does not click the Save button. Instead, the user closes the browser or 
> uses the navigation to go to a different part of the application. When 
> navigating back to the original agenda, the changes made previously (e.g. 
>   items added) are still being displayed, even
>though they were never explicitly saved.
 
 Here is what I don’t understand: how did the change get from the user’s 
 client agent (browser) to the server? If you make a change to a 

Re: [Pharo-users] voyage mongo and transactionality

[jtuc...@objektfabrik.de]

Am 09.10.19 um 16:48 schrieb jtuc...@objektfabrik.de:


In my experience, this problem area makes for the other 70% of the 
time spent on developing GUI or Web applications, besides the 60% for 
GUI design and implementation and 25% business logic...



I forgot the 30% for O/R Mapping when you use an ORM ;-)


Joachim


--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Re: [Pharo-users] voyage mongo and transactionality

[jtuc...@objektfabrik.de]

This is a tricky mine field. Sometimes you need a lot of business 
functionality in objects referenced in your objects that are currently 
in the editor. So I'm still to see a project in which the memento 
pattern really worked for more complex scenarios. How deep do you dive 
to have enough memento objects to provide the functionality needed. I 
guess you can do that with some sort of object-level transaction 
framework that automatically creates mementos of whatever object is 
being navigated to during some kind of processing-context. I guess slots 
could be of use here. But this is not trivial for general cases.


In my experience, this problem area makes for the other 70% of the time 
spent on developing GUI or Web applications, besides the 60% for GUI 
design and implementation and 25% business logic...


I'd be interested to learn about patterns to handle such more complex 
things. We constantly travel back and forth between implementing stuff 
in the GUI handlers (copying values to the GUI classes that access 
themselves during GUI operations and push values to the business objects 
when the users clicks on OK), using mementos (which most of the times 
are nets of mementos that are created manually - "we know what we'll 
touch in this Editor") and operating on business objects directly and 
relying on the persistence mechanism (Glorp in our case) and its 
rollback behaviour. All three have lots of weaknesses and seem to have 
their place nevertheless.


So this is a very interesting discussion and I think this is an area 
that has not been solved yet.



Joachim







Am 09.10.19 um 16:25 schrieb James Foster:
Thanks for the explanation. And, yes, this is an artifact of your 
design; if you put intermediate values into domain objects then they 
will remain in your domain objects to be seen later. From what you’ve 
described, I don’t see how it would be any different in a non-image 
environment (Java, C#, etc.), unless you re-read the entire object 
graph from the database. As someone else mentioned, this would be a 
good place for the Memento Pattern.


James

On Oct 9, 2019, at 1:59 AM, Jonathan van Alteren 
mailto:jvalte...@objectguild.com>> wrote:


Hi James,

I see how my explanation might be unclear.

We have a main form for the agenda and a subform for an item, which 
is shown using Seaside call/answer. The save button of the subform is 
clicked, which adds the item to the underlying agenda model object, 
but the save button of the main form _is not_ clicked by the user. 
The callback for the main save button sends the save message to the 
agenda object, causing the database to be updated.


So yes, the browser does submit the data on the subform, it's the 
main form component that doesn't receive the save button callback. I 
realize that this is in large part an issue with our design. However, 
the way object persistence seems to work in the image environment 
plays a large role.



Kind regards,

Jonathan van Alteren

Founding Member | Object Guild
jvalte...@objectguild.com 
On 8 Oct 2019, 15:41 +0200, James Foster >, wrote:


On Oct 8, 2019, at 3:05 AM, Jonathan van Alteren 
mailto:jvalte...@objectguild.com>> wrote:


We've encountered an issue where a user makes changes to an agenda, 
but does not click the Save button. Instead, the user closes the 
browser or uses the navigation to go to a different part of the 
application. When navigating back to the original agenda, the 
changes made previously (e.g. items added) are still being 
displayed, even though they were never explicitly saved.


Here is what I don’t understand: how did the change get from the 
user’s client agent (browser) to the server? If you make a change to 
a field in a form and then close the browser, who sent the change to 
the server? If you show the save domain value in a different 
location, with a dynamically-generated id and name (so it isn’t 
cached in the browser), or written to the Pharo Transcript, does the 
value still change? That is, are you sure that the change is in the 
reflected in the Smalltalk image and not just somehow cached in the 
browser?


James






--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Re: [Pharo-users] voyage mongo and transactionality

[James Foster]

Thanks for the explanation. And, yes, this is an artifact of your design; if 
you put intermediate values into domain objects then they will remain in your 
domain objects to be seen later. From what you’ve described, I don’t see how it 
would be any different in a non-image environment (Java, C#, etc.), unless you 
re-read the entire object graph from the database. As someone else mentioned, 
this would be a good place for the Memento Pattern.

James

> On Oct 9, 2019, at 1:59 AM, Jonathan van Alteren  
> wrote:
> 
> Hi James,
> 
> I see how my explanation might be unclear.
> 
> We have a main form for the agenda and a subform for an item, which is shown 
> using Seaside call/answer. The save button of the subform is clicked, which 
> adds the item to the underlying agenda model object, but the save button of 
> the main form is not clicked by the user. The callback for the main save 
> button sends the save message to the agenda object, causing the database to 
> be updated.
> 
> So yes, the browser does submit the data on the subform, it's the main form 
> component that doesn't receive the save button callback. I realize that this 
> is in large part an issue with our design. However, the way object 
> persistence seems to work in the image environment plays a large role. 
> 
> 
> Kind regards,
> 
> Jonathan van Alteren
> 
> Founding Member | Object Guild
> jvalte...@objectguild.com
> On 8 Oct 2019, 15:41 +0200, James Foster , wrote:
>> 
>>> On Oct 8, 2019, at 3:05 AM, Jonathan van Alteren 
>>>  wrote:
>>> 
>>> We've encountered an issue where a user makes changes to an agenda, but 
>>> does not click the Save button. Instead, the user closes the browser or 
>>> uses the navigation to go to a different part of the application. When 
>>> navigating back to the original agenda, the changes made previously (e.g. 
>>> items added) are still being displayed, even though they were never 
>>> explicitly saved.
>> 
>> Here is what I don’t understand: how did the change get from the user’s 
>> client agent (browser) to the server? If you make a change to a field in a 
>> form and then close the browser, who sent the change to the server? If you 
>> show the save domain value in a different location, with a 
>> dynamically-generated id and name (so it isn’t cached in the browser), or 
>> written to the Pharo Transcript, does the value still change? That is, are 
>> you sure that the change is in the reflected in the Smalltalk image and not 
>> just somehow cached in the browser?
>> 
>> James
>> 
>> 

Re: [Pharo-users] Spec2 and Gtk3

[Steve Quezadas]

Can't wait. You guys are doing an amazing job with this Glamorous Toolkit
stuff!

On Wed, Oct 9, 2019 at 5:04 AM Cyril Ferlicot 
wrote:

> On Wed, Oct 9, 2019 at 11:47 AM Shaping  wrote:
> >
> > Is there an ETA for Pharo's Spec2 with Gtk3 bindings?
> >
>
> Hi,
>
> The project is currently in development and should have a stable
> version for the Pharo 8 release.
>
>
> > When is the earliest I can test it?
> >
> >
> > Shaping
> >
> >
> >
>
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>
>

Re: [Pharo-users] How to zip a WideString

[Sven Van Caekenberghe]

Actually, thinking about the original use case, I now feel that it would be 
best to remove #zipped/unzipped from String.

The original problem was that

  'Les élèves Françaises ont 100 €' zipped unzipped.

does not work (it fails on WideStrings), while we now have

  'Les élèves Françaises ont 100 €' utf8Encoded zipped unzipped utf8Decoded.

which I would consider better form/style.

The original is also very confusing, since the result of zipping is not a 
string but binary.

> On 3 Oct 2019, at 13:21, Tomohiro Oda  wrote:
> 
> Sven,
> 
> Yes, ByteArray>>zipped/unzipped are simple, neat and intuitive way of
> zipping/unzipping binary data.
> I also love the new idioms. They look clean and concise.
> 
> Best Regards,
> ---
> tomo
> 
> 2019年10月3日(木) 20:14 Sven Van Caekenberghe :
>> 
>> Actually, thinking about this a bit more, why not add #zipped #unzipped to 
>> ByteArray ?
>> 
>> 
>> ByteArray>>#zipped
>>  "Return a GZIP compressed version of the receiver as a ByteArray"
>> 
>>  ^ ByteArray streamContents: [ :out |
>>  (GZipWriteStream on: out) nextPutAll: self; close ]
>> 
>> ByteArray>>#unzipped
>>  "Assuming the receiver contains GZIP encoded data,
>>   return the decompressed data as a ByteArray"
>> 
>>  ^ (GZipReadStream on: self) upToEnd
>> 
>> 
>> The original oneliner then becomes
>> 
>>  'string' utf8Encoded zipped.
>> 
>> and
>> 
>>  data unzipped utf8Decoded
>> 
>> which is pretty clear, simple and intention-revealing, IMHO.
>> 
>>> On 3 Oct 2019, at 13:04, Sven Van Caekenberghe  wrote:
>>> 
>>> Hi Tomo,
>>> 
>>> Indeed, I stand corrected, it does indeed seem possible to use the existing 
>>> gzip classes to work from bytes to bytes, this works fine:
>>> 
>>> data := ByteArray streamContents: [ :out | (GZipWriteStream on: out) 
>>> nextPutAll: 'foo 10 €' utf8Encoded; close ].
>>> 
>>> (GZipReadStream on: data) upToEnd utf8Decoded.
>>> 
>>> Now regarding the encoding option, I am not so sure that is really 
>>> necessary (though nice to have). Why would anyone use anything except UTF8 
>>> (today).
>>> 
>>> Thanks again for the correction !
>>> 
>>> Sven
>>> 
 On 3 Oct 2019, at 12:41, Tomohiro Oda  wrote:
 
 Peter and Sven,
 
 zip API from string to string works fine except that aWideString
 zipped generates malformed zip string.
 I think it might be a good guidance to define
 String>>zippedWithEncoding: and ByteArray>>unzippedWithEncoding: .
 Such as
 String>>zippedWithEncoding: encoder
 zippedWithEncoding: encoder
  ^ ByteArray
  streamContents: [ :stream |
  | gzstream |
  gzstream := GZipWriteStream on: stream.
  encoder
  next: self size
  putAll: self
  startingAt: 1
  toStream: gzstream.
  gzstream close ]
 
 and ByteArray>>unzippedWithEncoding: encoder
 unzippedWithEncoding: encoder
  | byteStream |
  byteStream := GZipReadStream on: self.
  ^ String
  streamContents: [ :stream |
  [ byteStream atEnd ]
  whileFalse: [ stream nextPut: (encoder nextFromStream:
 byteStream) ] ]
 
 Then, you can write something like
 zipped := yourLongWideString zippedWithEncoding: ZnCharacterEncoder utf8.
 unzipped := zipped unzippedWithEncoding: ZnCharacterEncoder utf8.
 
 This will not affect the existing zipped/unzipped API and you can
 handle other encodings.
 This zippedWithEncoding: generates a ByteArray, which is kind of
 conformant to the encoding API.
 And you don't have to create many intermediate byte arrays and byte 
 strings.
 
 I hope this helps.
 ---
 tomo
 
 2019/10/3(Thu) 18:56 Sven Van Caekenberghe :
> 
> Hi Peter,
> 
> About #zipped / #unzipped and the inflate / deflate classes: your 
> observation is correct, these work from string to string, while clearly 
> the compressed representation should be binary.
> 
> The contents (input, what is inside the compressed data) can be anything, 
> it is not necessarily a string (it could be an image, so also something 
> binary). Only the creator of the compressed data knows, you cannot assume 
> to know in general.
> 
> It would be possible (and it would be very nice) to change this, however 
> that will have serious impact on users (as the contract changes).
> 
> About your use case: why would your DB not be capable of storing large 
> strings ? A good DB should be capable of storing any kind of string (full 
> unicode) efficiently.
> 
> What DB and what sizes are we talking about ?
> 
> Sven
> 
>> On 3 Oct 2019, at 11:06, PBKResearch  wrote:
>> 
>> Hello
>> 
>> I have a problem with text storage, to which I seem to have found a 
>> solution, but it’s a bit clumsy-looking. I would be grateful for 
>> confirmation that (a) there 

Re: [Pharo-users] How to zip a WideString

[Sven Van Caekenberghe]

Richard,

Your implementation mixes zipping/unzipping and encoding/decoding, dictating a 
single way to do so, if I understand it correctly.

The composition with several messages allows for end users to choose their own 
encoding format, depending on their own needs, which I think is more flexible.

Sven 

> On 4 Oct 2019, at 06:36, Richard O'Keefe  wrote:
> 
> Here's how it would look in my library:
>   compressed := original zipped.
>  "There is currently one definition, in
> AbstractStringOrByteArray, covering [ReadOnly]ByteArray,
> [ReadOnly]String and its many subclasses,
>   ByteBuffer,StringBuffer, Substring, [ReadOnly]ShortArray,
> [ReadOnly]MappedByteArray, and some others.  This relies on
>   _ asByteArraySize and _ asByteArrayDo: _.  There is no need for
> a separate #utf8Encoded, that's what asByteArrayDo: *does*."
> 
>  copy := original class unzip: compressed.
>"This is a little trickier, but not hugely so.  There is no need
> for special case code.   [ReadOnly][Mapped]ByteArray and ByteBuffer
> are
> sequences of bytes, Stringy things are Unicode, and
> [ReadOnly]ShortArrays are treated as UTF16."
> 
> As far as I can tell, this just works for the original use case.
> 
> On Fri, 4 Oct 2019 at 11:42, PBKResearch  wrote:
>> 
>> Richard
>> 
>> I don't think so. The case being considered for my problem is the 
>> compression of a ByteArray produced by applying #utf8Encoded to a 
>> WideString, but it extends to any other form of ByteArray. If you substitute 
>> ByteArray for SomeClass in your examples, I think you will see why the 
>> chosen interface was used.
>> 
>> Peter Kenny
>> 
>> 
>> -Original Message-
>> From: Pharo-users  On Behalf Of Richard 
>> O'Keefe
>> Sent: 03 October 2019 23:08
>> To: Any question about pharo is welcome 
>> Subject: Re: [Pharo-users] How to zip a WideString
>> 
>> The interface should surely be
>>   SomeClass
>> methods for: 'compression'
>>   zipped "return a byte array"
>> 
>>class methods for: 'decompression'
>>  unzip: aByteArray "return an instance of SomeClass"
>> 
>> 
> 

Re: [Pharo-users] [ ANN ] Neo Universal Binary JSON

[Sven Van Caekenberghe]

> On 9 Oct 2019, at 14:29, Sven Van Caekenberghe  wrote:
> 
> The size/speed/efficiency differences are minor for typical JSON payloads, 
> especially compared with compacted JSON. The implementation is simpler, 
> though, as there is no string escaping and no number parsing.
> 
> UBJSON is making a larger difference when dealing with arrays containing 
> numbers. Especially with ByteArrays, UBJSON makes a huge difference, since 
> these are essentially stored natively.

Here are some details/benchmarks.


1. A typical JSON payload


data := ZnConstants httpStatusCodes associations 
  collect: [ :each | { #code->each key. #reason->each value } 
asDictionary ].

[ NeoUBJSONWriter toByteArray: data ] bench. "'11108.114 per second'"

bytes := NeoUBJSONWriter toByteArray: data.

bytes size. "2290"

[ NeoUBJSONReader fromByteArray: bytes ] bench. "'4412.670 per second'"

[ NeoJSONWriter toString: data ] bench. "'11542.783 per second'"

json := NeoJSONWriter toString: data.

json size. "2358"

[ NeoJSONReader fromString: json ] bench. "'4814.711 per second'"


2. A 1K integer array


data := (1 to: 1024) asArray.

[ NeoUBJSONWriter toByteArray: data ] bench. "'6945.444 per second'"

bytes := NeoUBJSONWriter toByteArray: data.

bytes size. "2822"

[ NeoUBJSONReader fromByteArray: bytes ] bench. "'3280.632 per second'"

[ NeoJSONWriter toString: data ] bench. "'4523.095 per second'"

json := NeoJSONWriter toString: data.

json size. "4014"

[ NeoJSONReader fromString: json ] bench. "'1253.749 per second'"


3. A 1K byte array


data := ByteArray new: 1024 streamContents: [ :out | 
  1024 timesRepeat: [ out nextPut: 256 atRandom - 1 ] ].

[ NeoUBJSONWriter toByteArray: data ] bench. "'538493.501 per second'"

bytes := NeoUBJSONWriter toByteArray: data.

bytes size. "1031"

[ NeoUBJSONReader fromByteArray: bytes ] bench. "'216269.200 per second'"

[ NeoJSONWriter toString: data ] bench. "'4579.084 per second'"

json := NeoJSONWriter toString: data.

json size. "3686"

[ NeoJSONReader fromString: json ] bench. "'1297.362 per second'"


Right now, only ByteArray got a highly optimised implementation. In the future, 
FloatArray and IntegerArray could receive the same treatment.

Sven

PS:

Note that UBJSON is not the same as BSON, nor CBOR, nor MessagePack, which all 
exist in the same space.
 

Re: [Pharo-users] [ ANN ] Neo Universal Binary JSON

[Sven Van Caekenberghe]

> On 9 Oct 2019, at 14:49, PBKResearch  wrote:
> 
> Sven
> 
> Excellent. Can the same idea be extended to STON - or is it there already?

I did not (yet) consider that, I will think about it.

However, Pharo contains two serialisation formats out of the box, STON, which 
is a textual format focusing on domain model objects, and FUEL, which is a fast 
binary format that can serialise special system objects as well.

> Peter Kenny
> 
> -Original Message-
> From: Pharo-users  On Behalf Of Sven
> Van Caekenberghe
> Sent: 09 October 2019 13:29
> To: Any question about pharo is welcome 
> Subject: [Pharo-users] [ ANN ] Neo Universal Binary JSON
> 
> Hi,
> 
> I just published an implementation of Universal Binary JSON (UBJSON) for
> Pharo.
> 
> https://github.com/svenvc/NeoUniversalBinaryJSON
> 
> Universal Binary JSON (UBJSON) is a computer data interchange format. It is
> a binary form directly imitating JSON, but requiring fewer bytes of data. It
> aims to achieve the generality of JSON, combined with being easier and more
> efficient to process than JSON.
> 
> http://ubjson.org
> https://en.wikipedia.org/wiki/UBJSON
> 
> The size/speed/efficiency differences are minor for typical JSON payloads,
> especially compared with compacted JSON. The implementation is simpler,
> though, as there is no string escaping and no number parsing.
> 
> UBJSON is making a larger difference when dealing with arrays containing
> numbers. Especially with ByteArrays, UBJSON makes a huge difference, since
> these are essentially stored natively.
> 
> Sven
> 
> 
> 

Re: [Pharo-users] [ ANN ] Neo Universal Binary JSON

[PBKResearch]

Sven

Excellent. Can the same idea be extended to STON - or is it there already?

Peter Kenny

-Original Message-
From: Pharo-users  On Behalf Of Sven
Van Caekenberghe
Sent: 09 October 2019 13:29
To: Any question about pharo is welcome 
Subject: [Pharo-users] [ ANN ] Neo Universal Binary JSON

Hi,

I just published an implementation of Universal Binary JSON (UBJSON) for
Pharo.

https://github.com/svenvc/NeoUniversalBinaryJSON

Universal Binary JSON (UBJSON) is a computer data interchange format. It is
a binary form directly imitating JSON, but requiring fewer bytes of data. It
aims to achieve the generality of JSON, combined with being easier and more
efficient to process than JSON.

http://ubjson.org
https://en.wikipedia.org/wiki/UBJSON

The size/speed/efficiency differences are minor for typical JSON payloads,
especially compared with compacted JSON. The implementation is simpler,
though, as there is no string escaping and no number parsing.

UBJSON is making a larger difference when dealing with arrays containing
numbers. Especially with ByteArrays, UBJSON makes a huge difference, since
these are essentially stored natively.

Sven

Re: [Pharo-users] Number to VT_DECIMAL

[eftomi]

Thanks for the explanation and solution - it works flawlessly and efficient
:-)



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] [ ANN ] Neo Universal Binary JSON

[Noury Bouraqadi]

Excellent!

Thanks Sven for this as well as for all your other contributions to the 
community.


Noury

> On 9 Oct 2019, at 14:29, Sven Van Caekenberghe  wrote:
> 
> Hi,
> 
> I just published an implementation of Universal Binary JSON (UBJSON) for 
> Pharo.
> 
> https://github.com/svenvc/NeoUniversalBinaryJSON
> 
> Universal Binary JSON (UBJSON) is a computer data interchange format. It is a 
> binary form directly imitating JSON, but requiring fewer bytes of data. It 
> aims to achieve the generality of JSON, combined with being easier and more 
> efficient to process than JSON.
> 
> http://ubjson.org
> https://en.wikipedia.org/wiki/UBJSON
> 
> The size/speed/efficiency differences are minor for typical JSON payloads, 
> especially compared with compacted JSON. The implementation is simpler, 
> though, as there is no string escaping and no number parsing.
> 
> UBJSON is making a larger difference when dealing with arrays containing 
> numbers. Especially with ByteArrays, UBJSON makes a huge difference, since 
> these are essentially stored natively.
> 
> Sven
> 
> 

[Pharo-users] [ ANN ] Neo Universal Binary JSON

[Sven Van Caekenberghe]

Hi,

I just published an implementation of Universal Binary JSON (UBJSON) for Pharo.

https://github.com/svenvc/NeoUniversalBinaryJSON

Universal Binary JSON (UBJSON) is a computer data interchange format. It is a 
binary form directly imitating JSON, but requiring fewer bytes of data. It aims 
to achieve the generality of JSON, combined with being easier and more 
efficient to process than JSON.

http://ubjson.org
https://en.wikipedia.org/wiki/UBJSON

The size/speed/efficiency differences are minor for typical JSON payloads, 
especially compared with compacted JSON. The implementation is simpler, though, 
as there is no string escaping and no number parsing.

UBJSON is making a larger difference when dealing with arrays containing 
numbers. Especially with ByteArrays, UBJSON makes a huge difference, since 
these are essentially stored natively.

Sven

Re: [Pharo-users] Spec2 and Gtk3

[Shaping]

The project is currently in development and should have a stable version for 
the Pharo 8 release.

 

When does the Pharo 8 release happen?

 

 

Shaping 

 

Re: [Pharo-users] Spec2 and Gtk3

[Cyril Ferlicot]

On Wed, Oct 9, 2019 at 11:47 AM Shaping  wrote:
>
> Is there an ETA for Pharo's Spec2 with Gtk3 bindings?
>

Hi,

The project is currently in development and should have a stable
version for the Pharo 8 release.


> When is the earliest I can test it?
>
>
> Shaping
>
>
>


-- 
Cyril Ferlicot
https://ferlicot.fr

[Pharo-users] Spec2 and Gtk3

[Shaping]

Is there an ETA for Pharo's Spec2 with Gtk3 bindings?

When is the earliest I can test it?


Shaping

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Esteban Maringolo]

On Wed, Oct 9, 2019 at 10:50 AM Esteban Lorenzano  wrote:

> There are a lot of things to consider, not just the native widgets.

> For example: how do you run those widgets? Because you need an event loop… 
> and while linux and windows do not care in which thread you run this, macOS 
> requires you to run it in the main thread.
> This means you need to run the VM using one of two strategies:
>
> 1) using the idle signal of Gtk (in case of gtk, but other frameworks have 
> similar things). This is of course suboptimal and forget about real-time 
> processing.
> 2) running the VM in a separated thread. This works as expected (and it also 
> follow apple application design recommendations) but then you need to make 
> sure the communication between the main thread and your vm thread work as 
> expected (and is not so easy)
>
> With Pablo we are working on (2), and I have to say that yes, if you do not 
> manage well things, you will not have more speed “just because” :)

This is great. Android does the same thing as MacOS, and it is even
enforced by the OS, it will mark any app as unresponsive if it blocks
the UI thread.
You can fork Threads that communicate with the UI thread by means of a
"Handler" [1], to map this using a dynamic language is simpler, but
you'd need an event loop in the UI first (I don't know whether we have
this in Pharo).

Regards,

[1] https://developer.android.com/training/multiple-threads/communicate-ui

Esteban A. Maringolo

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Shaping]

On 9 Oct 2019, at 10:33, giorgio ferraris mailto:giorgio.ferra...@gmail.com> > wrote:

 

for what I know  it's the way it's integrated with the underlain OS.  On 
windows things are much,  much  better.

 

VW emulates GUIs well, but I would not expect it to beat native.   I would 
restate it as : I would not expect native to be slower that emulated  :) 
seems the same, but not exactly… 

 

There are a lot of things to consider, not just the native widgets. 

For example: how do you run those widgets? Because you need an event loop… and 
while linux and windows do not care in which thread you run this, macOS 
requires you to run it in the main thread. 

 

Okay.

 

This means you need to run the VM using one of two strategies: 

 

1)  using the idle signal of Gtk (in case of gtk, but other frameworks have 
similar things). This is of course suboptimal and forget about real-time 
processing. 

 

 

Yes.

 

2)  running the VM in a separated thread. This works as expected (and it 
also follow apple application design recommendations) but then you need to make 
sure the communication between the main thread and your vm thread work as 
expected (and is not so easy)

 

How efficient is the signaling/queuing between the threads?

 

 

Shaping





 

On Wed, Oct 9, 2019 at 4:17 AM Shaping mailto:shap...@uurda.org> > wrote:

Regarding native widget, on the VW side the usage on them brought slowness on 
the OSX platform. Windows platform is speedy, but OSX platform is slower using 
native widget than with emulated ones.

So native widget alone are not always a solution. 

 

That’s interesting and unexpected (I don’t use OSX).  I would think that 
something is wrong with the VW native implementation or interface to it.  VW 
emulates GUIs well, but I would not expect it to beat native.   

 

Shaping

 

On Mon, Oct 7, 2019 at 2:08 PM Esteban Lorenzano mailto:esteba...@gmail.com> > wrote:

 

 

On 7 Oct 2019, at 12:39, Shaping mailto:shap...@uurda.org> 
> wrote:

 

I haven't seen is the instability of the VM you mention, it has worked pretty 
well for my average use, although the UX is not straightforward.

 

Yes, lots of redirection and extra steps.  Many degrees of freedom.  Seemingly 
no good default “happy” path to simplify things a little before you start to 
investigate the variations/choices.

 

> The other thing that keeps me planted firmly in VW is the sheer speed of it.

 

I don't know if there are recent benchmarks, but I've felt Pharo to be really 
fast compared to VW when it comes to computing.

 

I’ve don’t plenty of informal comparative testing mostly with the GUI.   I’ve 
used VW continuously for 29 years and Pharo on and off since 2006.  (I’m really 
trying to port, but I keep failing to do it; getting closer).   VW is still 
noticeably quicker in GUI responsiveness, in most cases.  One big difference is 
the Pharo HTTP client, with all those wonderful primitives.  It’s about twice 
as fast as VW’s.  Bravo.  I meant to tell that to Sven recently, and forgot.

 

> Pharo looks generally much better, but it’s mushy, and that’s a problem.  VW 
> is not.

 

Working regularly with VW or VAST when I go back to Pharo the "mushiness" is 
significantly noticeable, but if you open a Pharo 3 image (or even Pharo 4) 
you'll feel it really "snappy", but of course you'll lose all the improvements 
since then; and that's the current tradeoff.’

 

Yeah, I guess all the new slick GUIs are a bit heavier.  This machine is just 
okay for speed –2.7 GHz Xeon, but VW feels okay.  Pharo tends to put me slowly 
to sleep with the tiny but noticeable lags here and there.   I’m very fond of 
GT.  Beautiful.   Not sure what to do go get the GUI quickness back.  Maybe you 
 guys are waiting for the new GUI framework(s) to firm up?   I tried Cuis, and 
was not impressed.  It’s too lean/Spartan and still not very fast (slower in 
some ways than Pharo).  I like the Pharo creature-comforts (who wouldn’t?).  

 

I never understood the reason for the incremental slowdown, it is even present 
in "modern" tools such as GTToolkit.

 

Yes, it’s like a creeping disease.  Lol

 

Another thing I miss enough to want to implement (or fake-out somehow) is 
Alt-tabbing as a way to get around thru your browsers. Usually I have 4 to 6 up 
at once, if I’m behaving, and as many as 20 if I’m not.   Looking about for the 
tabs at the bottom to click is not nearly as fun as Alt-Tabbing.  Maybe I could 
emulate Alt-Tab with Alt-Shift-Tab—a bit of a finger twister, but it might work.

 

> Gestural dynamics are very quick, well under 100 ms latency, often less than 
> 20 ms.

> I’m seeing 100, 150, and 200 ms regularly in Pharo.  It’s too mushy, and that 
> slows the mind.

> Any developer understands this, whether he talks about it or not.

 

This is true, below 20ms is ideal, and top-notch CLI terminals are benchmarking 
this as a selling point (using stuff like  
 

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Shaping]

for what I know  it's the way it's integrated with the underlain OS.  On 
windows things are much,  much  better.

 

VW emulates GUIs well, but I would not expect it to beat native.   I would 
restate it as : I would not expect native to be slower that emulated  :) 
seems the same, but not exactly... 

 

Indeed.  I don’t follow OSX design, but would not expect such poor native 
performance from Apple.  I don’t get it.

 

Shaping

 

On Wed, Oct 9, 2019 at 4:17 AM Shaping mailto:shap...@uurda.org> > wrote:

Regarding native widget, on the VW side the usage on them brought slowness on 
the OSX platform. Windows platform is speedy, but OSX platform is slower using 
native widget than with emulated ones.

So native widget alone are not always a solution. 

 

That’s interesting and unexpected (I don’t use OSX).  I would think that 
something is wrong with the VW native implementation or interface to it.  VW 
emulates GUIs well, but I would not expect it to beat native.   

 

Shaping

 

On Mon, Oct 7, 2019 at 2:08 PM Esteban Lorenzano mailto:esteba...@gmail.com> > wrote:

 

 

On 7 Oct 2019, at 12:39, Shaping mailto:shap...@uurda.org> 
> wrote:

 

I haven't seen is the instability of the VM you mention, it has worked pretty 
well for my average use, although the UX is not straightforward.

 

Yes, lots of redirection and extra steps.  Many degrees of freedom.  Seemingly 
no good default “happy” path to simplify things a little before you start to 
investigate the variations/choices.

 

> The other thing that keeps me planted firmly in VW is the sheer speed of it.

 

I don't know if there are recent benchmarks, but I've felt Pharo to be really 
fast compared to VW when it comes to computing.

 

I’ve don’t plenty of informal comparative testing mostly with the GUI.   I’ve 
used VW continuously for 29 years and Pharo on and off since 2006.  (I’m really 
trying to port, but I keep failing to do it; getting closer).   VW is still 
noticeably quicker in GUI responsiveness, in most cases.  One big difference is 
the Pharo HTTP client, with all those wonderful primitives.  It’s about twice 
as fast as VW’s.  Bravo.  I meant to tell that to Sven recently, and forgot.

 

> Pharo looks generally much better, but it’s mushy, and that’s a problem.  VW 
> is not.

 

Working regularly with VW or VAST when I go back to Pharo the "mushiness" is 
significantly noticeable, but if you open a Pharo 3 image (or even Pharo 4) 
you'll feel it really "snappy", but of course you'll lose all the improvements 
since then; and that's the current tradeoff.’

 

Yeah, I guess all the new slick GUIs are a bit heavier.  This machine is just 
okay for speed –2.7 GHz Xeon, but VW feels okay.  Pharo tends to put me slowly 
to sleep with the tiny but noticeable lags here and there.   I’m very fond of 
GT.  Beautiful.   Not sure what to do go get the GUI quickness back.  Maybe you 
 guys are waiting for the new GUI framework(s) to firm up?   I tried Cuis, and 
was not impressed.  It’s too lean/Spartan and still not very fast (slower in 
some ways than Pharo).  I like the Pharo creature-comforts (who wouldn’t?).  

 

I never understood the reason for the incremental slowdown, it is even present 
in "modern" tools such as GTToolkit.

 

Yes, it’s like a creeping disease.  Lol

 

Another thing I miss enough to want to implement (or fake-out somehow) is 
Alt-tabbing as a way to get around thru your browsers. Usually I have 4 to 6 up 
at once, if I’m behaving, and as many as 20 if I’m not.   Looking about for the 
tabs at the bottom to click is not nearly as fun as Alt-Tabbing.  Maybe I could 
emulate Alt-Tab with Alt-Shift-Tab—a bit of a finger twister, but it might work.

 

> Gestural dynamics are very quick, well under 100 ms latency, often less than 
> 20 ms.

> I’m seeing 100, 150, and 200 ms regularly in Pharo.  It’s too mushy, and that 
> slows the mind.

> Any developer understands this, whether he talks about it or not.

 

This is true, below 20ms is ideal, and top-notch CLI terminals are benchmarking 
this as a selling point (using stuff like  
 
https://github.com/pavelfatin/typometer), Sublime, TextEdit, Notepad++ measure 
sub 10ms latency.

 

Indeed.

 

My whole nervous system definitely feels this speed effect and starts to 
thought-glide better below these tiny latencies.  I’m sure many reading this 
have had similar experiences.  Something similar happens when you are fortunate 
enough to use a machine with extremely fast striped SSD drives, where you 
literally don’t wait for anything, except the bloody internet.  This doesn’t 
just change the speed at which you do the work.  It reorganizes your mind and 
skills in ways you had not anticipated because you can flow so much more 
quickly, making connections further forward and backward in your thought 
stream.  My point is that if the speed and low-latencies are made a priority, 
we can attract users just on this basis alone. 

Re: [Pharo-users] Number to VT_DECIMAL

[Richard O'Keefe]

Whoops, Visual Age uses 17 BYTES, not 17 BITS.  Slaps own wrist.

On Wed, 9 Oct 2019 at 22:03, Richard O'Keefe  wrote:
>
> VT_DECIMAL sounds like a very close match to ScaledDecimal.
> Or it would if ScaledDecimal were consistently implemented between Smalltalks.
> The intent behind ScaledDecimal in the ANSI Smalltalk standard appears to
> have been an (m,p) representation where m and p are Integers standing for
> m * 10^p, for interoperation with DECIMAL fields in SQL databases (and of
> course with legacy code in COBOL and PL/I). This
> seems clear enough: 'Scaled decimal objects provide a precise representation 
> of
> decimal fractions with an explicitly specified number of fractional digits.'
>
> That's not what VisualWorks, Squeak, and Pharo actually do.  Instead
> they use a (q,p)
> representation where q is an *arbitrary* Fraction and p just says how many
> decimal places to *print*.  This leads to some very confusing results, and 
> means
> that the class *invented* to handle decimal fixed point is no more
> helpful to you in
> Pharo than Fraction is.  The reason VW gives is that it "seems useful" that
> 1000s0/7 * 7 should equal 1000s0, but that's actually *not* a useful
> property for an
> interoperability class.  If I want a Fraction, I know where to find
> it, and if I want it
> printed to a certain number of decimal places, I know how to do *that* without
> needing a complete number class for the purpose.
>
> VisualAge Smalltalk represents a decimal number as an array of 17 bits, which 
> is
> a bit more adequate than VT_DECIMAL, and is precisely the IBM mainframe
> "packed decimal" format with an extra byte for a scale.
>
> So what should you do?  Basically, a VT_DECIMAL is a pair (m,p,s) where
> m between: 0 and: (2 raisedTo: 96) - 1, p between: 0 and: 28, and
> s between: 0 and 1.  So
>
> Number
>   methods for: 'converting'
> asVtDecimalParts: p "p is the desired scale"
>   |m s|
>   s := 0.
>   m := (self * (10 raisedToInteger: p)) rounded.
>   m < 0 ifTrue: [s := 1. m := m negated].
>   ^Array with: m with: p with: s
>
> Note that with a Fraction, saying "is the denominator a power of 10,
> and if so which?"
> won't work, because 7/5 has a denominator that is not a power of 10 but it is
> exactly representable as 1.4s1.  And in both ANSI Smalltalk and VT_DECIMAL,
> the numbers 1.4s1, 1.40s2, 1.400s3, and so on are distinguishable.  So the 
> scale
> *has* to be something over and above the numeric value.  To put it another 
> way,
> the scale is determined by what the external application WANTS, not what the
> Smalltalk code HAS.
>
> On Wed, 9 Oct 2019 at 09:24, eftomi  wrote:
> >
> > Hi, I'm preparing a method to write a given Pharo's numerical value into an
> > external variant of type VT_DECIMAL. The purpose of this type is to retain
> > accuracy, it uses 12 bytes for "mantissa" and two bytes for a sign and a
> > scale (i. e. the position of decimal point). What would be the best approach
> > for the conversion, taken all the possible subclasses of class Number, that
> > is a Float, a Fraction and the Integers, and to keep the accuracy at the
> > same level?
> >
> > For instance, Fraction's numerator and denominator could be directly imputed
> > into VT_DECIMAL's value and scale if denominator is a power of 10. What to
> > do in other cases?
> >
> > A nice description of VT_DECIMAL is  here
> > 
> > .
> >
> > Best wishes,
> > Tomaz
> >
> >
> >
> > --
> > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> >

Re: [Pharo-users] Number to VT_DECIMAL

[Richard O'Keefe]

VT_DECIMAL sounds like a very close match to ScaledDecimal.
Or it would if ScaledDecimal were consistently implemented between Smalltalks.
The intent behind ScaledDecimal in the ANSI Smalltalk standard appears to
have been an (m,p) representation where m and p are Integers standing for
m * 10^p, for interoperation with DECIMAL fields in SQL databases (and of
course with legacy code in COBOL and PL/I). This
seems clear enough: 'Scaled decimal objects provide a precise representation of
decimal fractions with an explicitly specified number of fractional digits.'

That's not what VisualWorks, Squeak, and Pharo actually do.  Instead
they use a (q,p)
representation where q is an *arbitrary* Fraction and p just says how many
decimal places to *print*.  This leads to some very confusing results, and means
that the class *invented* to handle decimal fixed point is no more
helpful to you in
Pharo than Fraction is.  The reason VW gives is that it "seems useful" that
1000s0/7 * 7 should equal 1000s0, but that's actually *not* a useful
property for an
interoperability class.  If I want a Fraction, I know where to find
it, and if I want it
printed to a certain number of decimal places, I know how to do *that* without
needing a complete number class for the purpose.

VisualAge Smalltalk represents a decimal number as an array of 17 bits, which is
a bit more adequate than VT_DECIMAL, and is precisely the IBM mainframe
"packed decimal" format with an extra byte for a scale.

So what should you do?  Basically, a VT_DECIMAL is a pair (m,p,s) where
m between: 0 and: (2 raisedTo: 96) - 1, p between: 0 and: 28, and
s between: 0 and 1.  So

Number
  methods for: 'converting'
asVtDecimalParts: p "p is the desired scale"
  |m s|
  s := 0.
  m := (self * (10 raisedToInteger: p)) rounded.
  m < 0 ifTrue: [s := 1. m := m negated].
  ^Array with: m with: p with: s

Note that with a Fraction, saying "is the denominator a power of 10,
and if so which?"
won't work, because 7/5 has a denominator that is not a power of 10 but it is
exactly representable as 1.4s1.  And in both ANSI Smalltalk and VT_DECIMAL,
the numbers 1.4s1, 1.40s2, 1.400s3, and so on are distinguishable.  So the scale
*has* to be something over and above the numeric value.  To put it another way,
the scale is determined by what the external application WANTS, not what the
Smalltalk code HAS.

On Wed, 9 Oct 2019 at 09:24, eftomi  wrote:
>
> Hi, I'm preparing a method to write a given Pharo's numerical value into an
> external variant of type VT_DECIMAL. The purpose of this type is to retain
> accuracy, it uses 12 bytes for "mantissa" and two bytes for a sign and a
> scale (i. e. the position of decimal point). What would be the best approach
> for the conversion, taken all the possible subclasses of class Number, that
> is a Float, a Fraction and the Integers, and to keep the accuracy at the
> same level?
>
> For instance, Fraction's numerator and denominator could be directly imputed
> into VT_DECIMAL's value and scale if denominator is a power of 10. What to
> do in other cases?
>
> A nice description of VT_DECIMAL is  here
> 
> .
>
> Best wishes,
> Tomaz
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

Re: [Pharo-users] voyage mongo and transactionality

[Jonathan van Alteren]

Hi James,

I see how my explanation might be unclear.

We have a main form for the agenda and a subform for an item, which is shown 
using Seaside call/answer. The save button of the subform is clicked, which 
adds the item to the underlying agenda model object, but the save button of the 
main form is not clicked by the user. The callback for the main save button 
sends the save message to the agenda object, causing the database to be updated.

So yes, the browser does submit the data on the subform, it's the main form 
component that doesn't receive the save button callback. I realize that this is 
in large part an issue with our design. However, the way object persistence 
seems to work in the image environment plays a large role.


Kind regards,

Jonathan van Alteren

Founding Member | Object Guild
jvalte...@objectguild.com
On 8 Oct 2019, 15:41 +0200, James Foster , wrote:
>
> > On Oct 8, 2019, at 3:05 AM, Jonathan van Alteren 
> >  wrote:
> >
> > We've encountered an issue where a user makes changes to an agenda, but 
> > does not click the Save button. Instead, the user closes the browser or 
> > uses the navigation to go to a different part of the application. When 
> > navigating back to the original agenda, the changes made previously (e.g. 
> > items added) are still being displayed, even though they were never 
> > explicitly saved.
>
> Here is what I don’t understand: how did the change get from the user’s 
> client agent (browser) to the server? If you make a change to a field in a 
> form and then close the browser, who sent the change to the server? If you 
> show the save domain value in a different location, with a 
> dynamically-generated id and name (so it isn’t cached in the browser), or 
> written to the Pharo Transcript, does the value still change? That is, are 
> you sure that the change is in the reflected in the Smalltalk image and not 
> just somehow cached in the browser?
>
> James
>
>

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Esteban Lorenzano]

> On 9 Oct 2019, at 10:33, giorgio ferraris  wrote:
> 
> for what I know  it's the way it's integrated with the underlain OS.  On 
> windows things are much,  much  better.
> 
> VW emulates GUIs well, but I would not expect it to beat native.   I would 
> restate it as : I would not expect native to be slower that emulated  :) 
> seems the same, but not exactly… 

There are a lot of things to consider, not just the native widgets. 
For example: how do you run those widgets? Because you need an event loop… and 
while linux and windows do not care in which thread you run this, macOS 
requires you to run it in the main thread. 
This means you need to run the VM using one of two strategies: 

1) using the idle signal of Gtk (in case of gtk, but other frameworks have 
similar things). This is of course suboptimal and forget about real-time 
processing. 
2) running the VM in a separated thread. This works as expected (and it also 
follow apple application design recommendations) but then you need to make sure 
the communication between the main thread and your vm thread work as expected 
(and is not so easy)

With Pablo we are working on (2), and I have to say that yes, if you do not 
manage well things, you will not have more speed “just because” :)

Esteban

> 
> ciao
> 
> giorgio
> 
> I hope to have time to look again at Pharo one of these days. But time is 
> always a scarce resource :)
> 
> On Wed, Oct 9, 2019 at 4:17 AM Shaping  > wrote:
> Regarding native widget, on the VW side the usage on them brought slowness on 
> the OSX platform. Windows platform is speedy, but OSX platform is slower 
> using native widget than with emulated ones.
> 
> So native widget alone are not always a solution. 
> 
>  
> 
> That’s interesting and unexpected (I don’t use OSX).  I would think that 
> something is wrong with the VW native implementation or interface to it.  VW 
> emulates GUIs well, but I would not expect it to beat native.  
> 
>  
> 
> Shaping
> 
>  
> 
> On Mon, Oct 7, 2019 at 2:08 PM Esteban Lorenzano  > wrote:
> 
>  
> 
> 
> 
> 
> On 7 Oct 2019, at 12:39, Shaping  > wrote:
> 
>  
> 
> I haven't seen is the instability of the VM you mention, it has worked pretty 
> well for my average use, although the UX is not straightforward.
> 
>  
> 
> Yes, lots of redirection and extra steps.  Many degrees of freedom.  
> Seemingly no good default “happy” path to simplify things a little before you 
> start to investigate the variations/choices.
> 
>  
> 
> > The other thing that keeps me planted firmly in VW is the sheer speed of it.
> 
>  
> 
> I don't know if there are recent benchmarks, but I've felt Pharo to be really 
> fast compared to VW when it comes to computing.
> 
>  
> 
> I’ve don’t plenty of informal comparative testing mostly with the GUI.   I’ve 
> used VW continuously for 29 years and Pharo on and off since 2006.  (I’m 
> really trying to port, but I keep failing to do it; getting closer).   VW is 
> still noticeably quicker in GUI responsiveness, in most cases.  One big 
> difference is the Pharo HTTP client, with all those wonderful primitives.  
> It’s about twice as fast as VW’s.  Bravo.  I meant to tell that to Sven 
> recently, and forgot.
> 
>  
> 
> > Pharo looks generally much better, but it’s mushy, and that’s a problem.  
> > VW is not.
> 
>  
> 
> Working regularly with VW or VAST when I go back to Pharo the "mushiness" is 
> significantly noticeable, but if you open a Pharo 3 image (or even Pharo 4) 
> you'll feel it really "snappy", but of course you'll lose all the 
> improvements since then; and that's the current tradeoff.’
> 
>  
> 
> Yeah, I guess all the new slick GUIs are a bit heavier.  This machine is just 
> okay for speed –2.7 GHz Xeon, but VW feels okay.  Pharo tends to put me 
> slowly to sleep with the tiny but noticeable lags here and there.   I’m very 
> fond of GT.  Beautiful.   Not sure what to do go get the GUI quickness back.  
> Maybe you  guys are waiting for the new GUI framework(s) to firm up?   I 
> tried Cuis, and was not impressed.  It’s too lean/Spartan and still not very 
> fast (slower in some ways than Pharo).  I like the Pharo creature-comforts 
> (who wouldn’t?).  
> 
>  
> 
> I never understood the reason for the incremental slowdown, it is even 
> present in "modern" tools such as GTToolkit.
> 
>  
> 
> Yes, it’s like a creeping disease.  Lol
> 
>  
> 
> Another thing I miss enough to want to implement (or fake-out somehow) is 
> Alt-tabbing as a way to get around thru your browsers. Usually I have 4 to 6 
> up at once, if I’m behaving, and as many as 20 if I’m not.   Looking about 
> for the tabs at the bottom to click is not nearly as fun as Alt-Tabbing.  
> Maybe I could emulate Alt-Tab with Alt-Shift-Tab—a bit of a finger twister, 
> but it might work.
> 
>  
> 
> > Gestural dynamics are very quick, well under 100 ms latency, often less 
> > than 20 ms.
> 
> > I’m 

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[giorgio ferraris]

for what I know  it's the way it's integrated with the underlain OS.  On
windows things are much,  much  better.

*VW emulates GUIs well, but I would not expect it to beat native*.   I
would restate it as : I would not expect native to be slower that
emulated  :) seems the same, but not exactly...

ciao

giorgio

I hope to have time to look again at Pharo one of these days. But time is
always a scarce resource :)

On Wed, Oct 9, 2019 at 4:17 AM Shaping  wrote:

> Regarding native widget, on the VW side the usage on them brought
> slowness on the OSX platform. Windows platform is speedy, but OSX platform
> is slower using native widget than with emulated ones.
>
> So native widget alone are not always a solution.
>
>
>
> That’s interesting and unexpected (I don’t use OSX).  I would think that
> something is wrong with the VW native implementation or interface to it.
> VW emulates GUIs well, but I would not expect it to beat native.
>
>
>
> Shaping
>
>
>
> On Mon, Oct 7, 2019 at 2:08 PM Esteban Lorenzano 
> wrote:
>
>
>
>
>
> On 7 Oct 2019, at 12:39, Shaping  wrote:
>
>
>
> I haven't seen is the instability of the VM you mention, it has worked
> pretty well for my average use, although the UX is not straightforward.
>
>
>
> Yes, lots of redirection and extra steps.  Many degrees of freedom.
> Seemingly no good default “happy” path to simplify things a little before
> you start to investigate the variations/choices.
>
>
>
> > The other thing that keeps me planted firmly in VW is the sheer speed of
> it.
>
>
>
> I don't know if there are recent benchmarks, but I've felt Pharo to be
> really fast compared to VW when it comes to computing.
>
>
>
> I’ve don’t plenty of informal comparative testing mostly with the GUI.
>   I’ve used VW continuously for 29 years and Pharo on and off since 2006.
> (I’m really trying to port, but I keep failing to do it; getting closer).
>  VW is still noticeably quicker in GUI responsiveness, in most cases.  One
> big difference is the Pharo HTTP client, with all those wonderful
> primitives.  It’s about *twice as fast* as VW’s.  Bravo.  I meant to tell
> that to Sven recently, and forgot.
>
>
>
> > Pharo looks generally much better, but it’s mushy, and that’s a
> problem.  VW is not.
>
>
>
> Working regularly with VW or VAST when I go back to Pharo the "mushiness"
> is significantly noticeable, but if you open a Pharo 3 image (or even Pharo
> 4) you'll feel it really "snappy", but of course you'll lose all the
> improvements since then; and that's the current tradeoff.’
>
>
>
> Yeah, I guess all the new slick GUIs are a bit heavier.  This machine is
> just okay for speed –2.7 GHz Xeon, but VW feels okay.  Pharo tends to put
> me slowly to sleep with the tiny but noticeable lags here and there.   I’m
> very fond of GT.  Beautiful.   Not sure what to do go get the GUI quickness
> back.  Maybe you  guys are waiting for the new GUI framework(s) to firm
> up?   I tried Cuis, and was not impressed.  It’s too lean/Spartan and still
> not very fast (slower in some ways than Pharo).  I like the Pharo
> creature-comforts (who wouldn’t?).
>
>
>
> I never understood the reason for the incremental slowdown, it is even
> present in "modern" tools such as GTToolkit.
>
>
>
> Yes, it’s like a creeping disease.  Lol
>
>
>
> Another thing I miss enough to want to implement (or fake-out somehow) is
> Alt-tabbing as a way to get around thru your browsers. Usually I have 4 to
> 6 up at once, if I’m behaving, and as many as 20 if I’m not.   Looking
> about for the tabs at the bottom to click is not nearly as fun as
> Alt-Tabbing.  Maybe I could emulate Alt-Tab with Alt-Shift-Tab—a bit of a
> finger twister, but it might work.
>
>
>
> > Gestural dynamics are very quick, well under 100 ms latency, often less
> than 20 ms.
>
> > I’m seeing 100, 150, and 200 ms regularly in Pharo.  It’s too mushy, and
> that slows the mind.
>
> > Any developer understands this, whether he talks about it or not.
>
>
>
> This is true, below 20ms is ideal, and top-notch CLI terminals are
> benchmarking this as a selling point (using stuff like
> https://github.com/pavelfatin/typometer), Sublime, TextEdit, Notepad++
> measure sub 10ms latency.
>
>
>
> Indeed.
>
>
>
> My whole nervous system definitely feels this speed effect and starts to
> thought-glide better below these tiny latencies.  I’m sure many reading
> this have had similar experiences.  Something similar happens when you are
> fortunate enough to use a machine with extremely fast striped SSD drives,
> where *you literally don’t wait for anything*, except the bloody
> internet.  This doesn’t just change the speed at which you do the work.  It
> reorganizes your mind and skills in ways you had not anticipated because
> you can flow so much more quickly, making connections further forward and
> backward in your thought stream.  My point is that if the speed and
> low-latencies are made a priority, we can attract users just on this basis
> alone.  Even I would be