Re: [Pharo-users] [Moose-dev] [ann] gt documenter

[Tudor Girba]

Hi,

It looks like something broke in your Bloc. You can reset Bloc from the world 
menu / Bloc / Reset Bloc. Please let me know if it works.

Cheers,
Doru


> On Jun 26, 2018, at 12:54 AM, Tim Mackinnon  wrote:
> 
> Hi - so I managed to load up the full monty gtDocumentor into an image (a few 
> false starts as it you try and load the full monty on top of just 
> gtDocumentor e.g in a clean image load
> 
> Metacello new
>baseline: 'GToolkit';
>repository: '
> github://feenkcom/gtoolkit/src
> ';
>load.
> 
> On top of this
> Metacello new
>baseline: 'GToolkitDocumenter';
>repository: '
> github://feenkcom/gtoolkit-documenter/src
> ';
>load.
> 
> 
> It never completes - I gave up after 30 minutes and whining fans on a MacBook 
> Pro.
> 
> Anyway - in a completely clean image I loaded just GTookkit and then run
> 
> GtDocumenter editorForText: BrToggleExamples comment.
> 
> Which seemed to work fine - and showed me some buttons with different dots on 
> them.
> 
> So then I went and tried the example I really wanted to see:
> 
> IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit-examples' / 'doc' 
> / 'tutorial' / 'examples-tutorial.pillar’. 
> 
> And it just gives a blank tab in the _Pillar, _Contents and _GT tabs? The 
> contents tab does show me pillar text unrendered.
> 
> Interestingly, If I then go back to the previous editorForText example, that 
> did work - it now also also show the same blank tabs. So it seems that 
> something get broken?
> 
> This is on OSX with the a 64bit image - labelled 6.1 - 64bit (tech preview) - 
> so the current stable pharo for 64 bit.
> 
> Is this a known issue?
> 
> Tim
> 
> 
>> On 20 Jun 2018, at 02:53, Tim Mackinnon  wrote:
>> 
>> Actually I realised it ended up on the be moose forum - here’s what Doru 
>> replied (for any lurkers)
>> 
>> 
>> 
>> Sent from my iPhone
>>> On Jun 18, 2018, at 1:21 PM, Tim Mackinnon  wrote:
>>> 
>>> Guys this is really impressive!
>> 
>> Thanks.
>> 
>> 
>>> 2 things I noticed when going through the example in a new Pharo 6.1 image 
>>> (with the latest Iceberg) -
>>> 
>>> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
>>> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ 
>>> has changed to “IceLibgitRepository …” in the newer iceberg - so it might 
>>> be worth a note in the readme (I’ll submit a PR)
>> Show Quoted Content
>>> 2 things I noticed when going through the example in a new Pharo 6.1 image 
>>> (with the latest Iceberg) -
>>> 
>>> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
>>> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ 
>>> has changed to “IceLibgitRepository …” in the newer iceberg - so it might 
>>> be worth a note in the readme (I’ll submit a PR)
>> 
>> Ok.
>> 
>> 
>>> 2) In a clean 6.1 image I get a walkback (GtPhlowExplicitView>>mondrian 
>>> DNU) when you try any of the graphical bits , making me think either the 
>>> dependencies are incorrect  on the Baseline (or the instruction for the 
>>> example also need to mention you need to load something else - presumably 
>>> Roassal?
>> 
>> Indeed, this is due to the fact that loading GToolkitDocumenter does not 
>> load GToolkitVisualizer which includes GtMondrian. We are still working on 
>> finding the right dependencies balance.
>> 
>> Until then, please load the whole GToolkit to get the full support.
>> 
>> 
>>> 3) You can’t scroll the Diff tabs of results, only the Code tabs
>> 
>> Good catch!
>> 
>> 
>> Cheers,
>> Doru
>> 
>> Sent from my iPhone
>> 
>> On 20 Jun 2018, at 02:47, Tim Mackinnon  wrote:
>> 
>>> Bump (not sure this got through , and keen to know how to load the 
>>> diagramming bit)
>>> 
>>> Guys this is really impressive!
>>> 
>>> 2 things I noticed when going through the example in a new Pharo 6.1 image 
>>> (with the latest Iceberg) -
>>> 
>>> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
>>> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ 
>>> has changed to “IceLibgitRepository …” in the newer iceberg - so it might 
>>> be worth a note in the readme (I’ll submit a PR)
>>> 
>>> 2) In a clean 6.1 image I get a walkback (GtPhlowExplicitView>>mondrian 
>>> DNU) when you try any of the graphical bits , making me think either the 
>>> dependencies are incorrect  on the Baseline (or the instruction for the 
>>> example also need to mention you need to load something else - presumably 
>>> Roassal?
>>> 3) You can’t scroll the Diff tabs of results, only the Code tabs
>>> 
>>> Tim
>>> 
 On 13 Jun 2018, at 21:57, Tudor Girba  wrote:
 
 Hi,
 
 We are happy to announce a new leap of GToolkit Documenter, the tool for 
 manipulating live documents directly in the development environment:
 https://github.com/feenkcom/gtoolkit-documenter
 
 Documenter is part of the second generation GToolkit project, it is based 
 on Bloc and works with the latest Pillar. 

Re: [Pharo-users] [ANN] GNU Dr. Geo release 18.06

[H. Hirzel]

On 6/23/18, Hilaire  wrote:
> As a matter of accuracy, it is more active essays paradigm[1].
>
> Hilaire
>
> [1] http://www.vpri.org/pdf/tr2009002_active_essays.pdf

A good report by now 9 years old worth to be read again.

Maybe some discussion could be about this article and the way forward
 (small doable steps)


>
> Le 23/06/2018 à 08:17, Hilaire a écrit :
>> They call it Dynabook in the old time... Not yet there 40 years later,
>> we are damn slow.
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-users] copy & paste

[Otto Behrens]

Thanks for the answer.

We use the package installation for ubuntu described here:
https://pharo.org/gnu-linux-installation-64.

The stable version on opensuse is quite old. And apparently not 6.1. So,
does this sadly mean that the paragraph on the top of the page "Zip file"
is updated, but the rest of the page not?



On Sun, Jun 24, 2018 at 11:58 AM, Hilaire  wrote:

> Hi Otto,
>
> I had this issue, but it seems to be gone with P7, at least on the DrGeo
> build based on it I can copy and paste from Chromium.
>
> Hilaire
>
>
> Le 24/06/2018 à 11:11, Otto Behrens a écrit :
> >
> > A very annoying issue I'm having with Pharo 6.0 (running on Ubuntu
> > 16.04) is that if I copy text from other applications (eg. chromium
> > browser), I cannot paste it into Pharo. I get text copied in Pharo
> > from a previous copy.
> >
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-users] [Dynabook][Morphic][TLM][Geometry] Re: [ANN] GNU Dr. Geo release 18.06

[H. Hirzel]

P.S. This message was meant to be off-list.

But as it went out to the list unintentionally there will be some
small discussion participation from my side in case there is one   :-)

On 6/26/18, H. Hirzel  wrote:
> Hi Hilaire
>
>
> This message is off-list as I do not have the capacity NOW  to
> maintain a conversation on this list.
>
> See my comments below
>
> On 6/23/18, Hilaire  wrote:
>> Hi Ben,
>>
>> They call it Dynabook in the old time... Not yet there 40 years later,
>> we are damn slow.
>
> Yes indeed.
> Actually on the hardware level and the software for reading (e-books)
> and learning (teaching apps) the dynabook goal has been reached for
> many years by now.
>
> Even the price goal has been under-cut. For 100USD you get a nice
> tablet which is considerably less than the 300400 USD people
> originally thought of.
>
> And with OTG connections you may add a mouse and keyboard.
> Raspberry Pi is also very affordable and has millions of users.
>
> But just using laptops and PCs is also very fine.
>
>> As an educator, I am all days frustrated with the computed tools we
>> have, and the lack of integration.
>
> This is the main point. Lack of integration. And "authoring
> environments" for this.
>
>> Anyones crazy enough to work on this challenge?
>
> I think I am working on this. For quite some time. At the moment I
> work with Squeak though.
>
> But as Dr. Geo is using Morphic what I am doing may be extended to be
> used there as well.
>
> What I am doing is not so much inventing new things but making old
> things work. The solutions are actually around. They need to be
> documented and used. Demos and interaction is needed. Curriculum
> integration is then also quite an effort.
>
> I understand that you are in or around Geneva. Is that correct?
>
> Kind regards
> Hannes
>
>> Hilaire
>>
>>
>> Le 23/06/2018 à 02:03, Ben Coman a écrit :
>>> So now we need a DrGeo inside a live document providing a curriculum
>>> for teachers... ;) ?
>>>
>>> cheers -ben
>>>
>>
>> --
>> Dr. Geo
>> http://drgeo.eu
>>
>>
>>
>>
>

Re: [Pharo-users] copy & paste

[Otto Behrens]

Thanks for the help. Unfortunately, this does not work.

We actually ran it with --encoding UTF-8 --pathenc UTF-8 --textenc UTF-8
I tried utf8, UTF8 and with just --textenc

But I see our installation is relatively old. Will comment on another post
here.

On Sun, Jun 24, 2018 at 11:31 AM, Peter Uhnák  wrote:

> I thought that this was fixed a long time ago?
>
> Try running it with  --textenc utf8  and see if it fixes it.
>
> Peter
>
> On Sun, Jun 24, 2018 at 11:11 AM, Otto Behrens  wrote:
>
>> Hi,
>>
>> A very annoying issue I'm having with Pharo 6.0 (running on Ubuntu 16.04)
>> is that if I copy text from other applications (eg. chromium browser), I
>> cannot paste it into Pharo. I get text copied in Pharo from a previous copy.
>>
>> To work around this, I have a "gedit" text editor open and I paste the
>> text in there. After that, I cut it from the text editor and paste it into
>> pharo.
>>
>> So, it appears as if this may be an issue with text (/encoding?). Any
>> ideas?
>>
>> Thanks
>> Otto
>>
>
>

[Pharo-users] [Dynabook][Morphic][TLM][Geometry] Re: [ANN] GNU Dr. Geo release 18.06

[H. Hirzel]

Hi Hilaire


This message is off-list as I do not have the capacity NOW  to
maintain a conversation on this list.

See my comments below

On 6/23/18, Hilaire  wrote:
> Hi Ben,
>
> They call it Dynabook in the old time... Not yet there 40 years later,
> we are damn slow.

Yes indeed.
Actually on the hardware level and the software for reading (e-books)
and learning (teaching apps) the dynabook goal has been reached for
many years by now.

Even the price goal has been under-cut. For 100USD you get a nice
tablet which is considerably less than the 300400 USD people
originally thought of.

And with OTG connections you may add a mouse and keyboard.
Raspberry Pi is also very affordable and has millions of users.

But just using laptops and PCs is also very fine.

> As an educator, I am all days frustrated with the computed tools we
> have, and the lack of integration.

This is the main point. Lack of integration. And "authoring
environments" for this.

> Anyones crazy enough to work on this challenge?

I think I am working on this. For quite some time. At the moment I
work with Squeak though.

But as Dr. Geo is using Morphic what I am doing may be extended to be
used there as well.

What I am doing is not so much inventing new things but making old
things work. The solutions are actually around. They need to be
documented and used. Demos and interaction is needed. Curriculum
integration is then also quite an effort.

I understand that you are in or around Geneva. Is that correct?

Kind regards
Hannes

> Hilaire
>
>
> Le 23/06/2018 à 02:03, Ben Coman a écrit :
>> So now we need a DrGeo inside a live document providing a curriculum
>> for teachers... ;) ?
>>
>> cheers -ben
>>
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-users] Interesting Pharo Launcher feedback

[Ben Coman]

On 26 June 2018 at 06:17, Tim Mackinnon  wrote:

> Hi everyone - at tonights month UK Smalltalk Meetup, we got some nice
> compliments on the state of Pharo (the participants - all ex small talkers
> - although ex in so much as they fondly remembered it and wanted to use it
> for something relevant now because they enjoyed it in the past).
>
> Anyway, one interesting comment stuck out - he had downloaded Pharo
> (having used Visual Age 15+ years ago) and was a bit overwhelmed with what
> laugher presented to him. He didn’t hate it - but was initially a bit lost
> as to what it all meant and how to start… he figured it out, but I thought
> the feedback was interesting and made me think that maybe we need some form
> of intro wizard to get people off to a quick start but leave them confident
> enough that they might come back and try a Pharo 7 or Moose etc.
>
> I encouraged him to post something on here, but thoughtI would note it (as
> it seems quite easy to fix) as an idea while it was fresh in my mind.
>
>
A welcome tutorial is a good idea.  And btw, the sort of idea that only
comes from broader use of PharoLauncher.

cheers -ben

Re: [Pharo-users] [Moose-dev] [ann] gt documenter

[Tim Mackinnon]

Hi - so I managed to load up the full monty gtDocumentor into an image (a few 
false starts as it you try and load the full monty on top of just gtDocumentor 
e.g in a clean image load

Metacello new
   baseline: 'GToolkit';
   repository: 'github://feenkcom/gtoolkit/src';
   load.
On top of this
Metacello new
   baseline: 'GToolkitDocumenter';
   repository: 'github://feenkcom/gtoolkit-documenter/src';
   load.

It never completes - I gave up after 30 minutes and whining fans on a MacBook 
Pro.

Anyway - in a completely clean image I loaded just GTookkit and then run

GtDocumenter editorForText: BrToggleExamples comment.

Which seemed to work fine - and showed me some buttons with different dots on 
them.

So then I went and tried the example I really wanted to see:

IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit-examples' / 'doc' / 
'tutorial' / 'examples-tutorial.pillar’. 

And it just gives a blank tab in the _Pillar, _Contents and _GT tabs? The 
contents tab does show me pillar text unrendered.

Interestingly, If I then go back to the previous editorForText example, that 
did work - it now also also show the same blank tabs. So it seems that 
something get broken?

This is on OSX with the a 64bit image - labelled 6.1 - 64bit (tech preview) - 
so the current stable pharo for 64 bit.

Is this a known issue?

Tim


> On 20 Jun 2018, at 02:53, Tim Mackinnon  wrote:
> 
> Actually I realised it ended up on the be moose forum - here’s what Doru 
> replied (for any lurkers)
> 
> 
> 
> Sent from my iPhone
>> On Jun 18, 2018, at 1:21 PM, Tim Mackinnon > > wrote:
>> 
>> Guys this is really impressive!
> 
> Thanks.
> 
> 
> 2 things I noticed when going through the example in a new Pharo 6.1 image 
> (with the latest Iceberg) -
> 
> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ has 
> changed to “IceLibgitRepository …” in the newer iceberg - so it might be 
> worth a note in the readme (I’ll submit a PR)
> Show Quoted Content
> 2 things I noticed when going through the example in a new Pharo 6.1 image 
> (with the latest Iceberg) -
> 
> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ has 
> changed to “IceLibgitRepository …” in the newer iceberg - so it might be 
> worth a note in the readme (I’ll submit a PR)
>  2 things I noticed when going through the example 
> in a new Pharo 6.1 image (with the latest Iceberg) -
>> 
>> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
>> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ has 
>> changed to “IceLibgitRepository …” in the newer iceberg - so it might be 
>> worth a note in the readme (I’ll submit a PR)
> 
> Show Quoted Content
>> 2 things I noticed when going through the example in a new Pharo 6.1 image 
>> (with the latest Iceberg) -
>> 
>> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
>> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ has 
>> changed to “IceLibgitRepository …” in the newer iceberg - so it might be 
>> worth a note in the readme (I’ll submit a PR)
> 
> Ok.
> 
> 
>> 2) In a clean 6.1 image I get a walkback (GtPhlowExplicitView>>mondrian DNU) 
>> when you try any of the graphical bits , making me think either the 
>> dependencies are incorrect  on the Baseline (or the instruction for the 
>> example also need to mention you need to load something else - presumably 
>> Roassal?
> 
> Indeed, this is due to the fact that loading GToolkitDocumenter does not load 
> GToolkitVisualizer which includes GtMondrian. We are still working on finding 
> the right dependencies balance.
> 
> Until then, please load the whole GToolkit to get the full support.
> 
> 
>> 3) You can’t scroll the Diff tabs of results, only the Code tabs
> 
> Good catch!
> 
> 
> Cheers,
> Doru
> 
> Sent from my iPhone
> 
> On 20 Jun 2018, at 02:47, Tim Mackinnon  > wrote:
> 
>> Bump (not sure this got through , and keen to know how to load the 
>> diagramming bit)
>> 
>> Guys this is really impressive!
>> 
>> 2 things I noticed when going through the example in a new Pharo 6.1 image 
>> (with the latest Iceberg) -
>> 
>> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
>> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ has 
>> changed to “IceLibgitRepository …” in the newer iceberg - so it might be 
>> worth a note in the readme (I’ll submit a PR)
>> 
>> 2) In a clean 6.1 image I get a walkback (GtPhlowExplicitView>>mondrian DNU) 
>> when you try any of the graphical bits , making me think either the 
>> dependencies are incorrect  on the Baseline (or the instruction for the 
>> example also need to mention you need to load something else - presumably 
>> Roassal?
>> 3) You can’t scroll the Diff tabs of results, 

[Pharo-users] Interesting Pharo Launcher feedback

[Tim Mackinnon]

Hi everyone - at tonights month UK Smalltalk Meetup, we got some nice 
compliments on the state of Pharo (the participants - all ex small talkers - 
although ex in so much as they fondly remembered it and wanted to use it for 
something relevant now because they enjoyed it in the past).

Anyway, one interesting comment stuck out - he had downloaded Pharo (having 
used Visual Age 15+ years ago) and was a bit overwhelmed with what laugher 
presented to him. He didn’t hate it - but was initially a bit lost as to what 
it all meant and how to start… he figured it out, but I thought the feedback 
was interesting and made me think that maybe we need some form of intro wizard 
to get people off to a quick start but leave them confident enough that they 
might come back and try a Pharo 7 or Moose etc.

I encouraged him to post something on here, but thoughtI would note it (as it 
seems quite easy to fix) as an idea while it was fresh in my mind.

Tim 

Re: [Pharo-users] StCAD is open source

[Hilaire]

Impressive!

Hilaire


Le 25/06/2018 à 02:05, askoh a écrit :
> I have just open source StCAD (MIT license) which has the code for freeCAD.
> http://askoh.com/stcad
> Although written in VisualWorks Smalltalk, I hope Pharo users will port it
> in part or whole.

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Smalltalk Programming Competition

[horrido]

Today, GemTalk Systems donated $1,000!!! Wow!

We now have CA$1,970 from 12 generous contributors in 10 days. Le'ts make
this happen!

I've just completed the web application for the competition website. I will
deploy it as soon as it appears the competition is a go.

Still a lot of work ahead, but I'm pumped.



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

Re: [Pharo-users] StCAD is open source

[Offray Vladimir Luna Cárdenas]

Thanks a lot.

BTW, the page at [1] looks really good for a graphical software. Maybe
some of its looks could be put in the CAD software repos, just to give a
glimpse of what is possible with FreeCAD and StCAD.

[1] http://www.ar-cad.com/index.html

Cheers,

Offray


On 24/06/18 19:05, askoh wrote:
> Hi:
>
> I have just open source StCAD (MIT license) which has the code for freeCAD.
> http://askoh.com/stcad
> Although written in VisualWorks Smalltalk, I hope Pharo users will port it
> in part or whole.
>
> All the best,
> Aik-Siong Koh
>
> What is 'StCAD'?
>
> 'StCAD' is a basic 3D CAD framework in Smalltalk (VisualWorks 8.x). It
> extends
> the GF/ST 2D drawing framework into 3D. It also include 'StCAD-Geo' which is
> the 3D geometric domain, 'StCAD-Math' which provides the mathematical
> support
> for 3D CAD and motion simulation computations, and 'StCAD-Doc' which is a
> simple word processor. 'StCAD-Math' is also suitable for engineering,
> scientific and business computing. The parcels are open source using MIT
> License. Users can use these parcels with other private software to create
> 3D
> applications like motion simulation, finite element analysis, CAD,
> scientific
> visualization, etc.
>
> 'StCAD' allows users to create and manipulate assemblies, which are
> collections of 3D parts. The parts are 3D solids, which can be connected by
> joints, constraints, contacts, actuators, springs, dampers or forces. The
> parts and connections define the structure or mechanism that the assembly is
> meant to represent. Animation is possible, if the user can provide time
> series
> of position and orientation data for the parts.
>
> Users can also obtain output data in the form of plots and tables. XY plots
> can be zoomed and set to equal scales. Data series available include linear
> and angular displacements, velocities, accelerations and other user
> generated
> data.
>
> 'StCAD' has been used to create a freeware called 'freeCAD' which is a 3D
> CAD
> with Motion Simulation. For more information visit:
> http://www.askoh.com
>
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

Re: [Pharo-users] Pharo 7 streams API

[Richard O'Keefe]

Experience with Java taught me to loath ethe "do I/O
by composing lots of little wrappers" approach for
several reasons:
 - the fact that the commonest case was not the
   default case, so that simple obvious code was
   somewhere between disgracefully slow and wrong
 - the extra complexity needed to get it right
   (having to know a plethora of wrapper classes
   instead of just getting sensible defaults)
 - the poor performance.

In my own Smalltalk system I hewed to the ANSI
Smalltalk standard and if you do
FileStream read: aFileName
or  FileStream write: aFileName
you get a text file using the encoding set by
your environment's locale, the native line ending
convention, Simple, easy, and leaves Java's
I/O performance in the dust.

Of course wrappers are available for the rare
cases when you need them, but you don't _have_
to use them.  One reason this matters is that
there are two ways to write a stream:

  s2 := WrapperClass on: s1
-- closing s2 just closes s2, not s1.
  s2 := WrapperClass onOwn: s1
-- closing s2 closes s1 as well

And yes, both of these *are* used.


On 24 June 2018 at 04:53, Sven Van Caekenberghe  wrote:

> Peter,
>
> > On 23 Jun 2018, at 15:39, Peter Uhnák  wrote:
> >
> > Hi,
> >
> > I'm starting to familiarize myself with new streams, and one thing I've
> noticed is the removal of #lineEndConvention (which I use all the time).
> >
> > So a statement like this
> >
> > aFile writeStreamDo: [ :stream |
> >   stream lineEndConvention: #lf.
> >   stream << '...'
> > ].
> >
> > has to be written like so
> >
> > aFile writeStreamDo: [ :rawStream | |stream|
> >   stream := (ZnNewLineWriterStream on: rawStream) forLf.
> >   stream << '...'
> > ].
> >
> > which feels very messy because I am mixing writing with the
> configuration. And I don't even take account for buffered/encoded
> decorators. Plus it increases the incidental complexity -- I need another
> variable, and I can accidentally write to the wrong stream, etc.
> >
> > Would a method like #writeStream:do: (or #writeStreamTransform:do:) make
> sense? E.g.
> >
> > aFile writeStreamTransform: [ :stream | (ZnNewLineWriterStream on:
> stream) ] do: [ :stream |
> >   stream << '...'
> > ]
> >
> > To separate the composition from the usage?
> >
> > Thanks,
> > Peter
>
> The goals of the 'new' (they have existed for quite a while) streams is to
> go from single big complex do all classes and replace that with a
> composition of much simpler single purpose classes. Another goal is to
> reduce the API so that it becomes easier to create new stream classes. Of
> course, a consequence is that you need composition to get the functionality
> you want. But I think you understand the tradeoff.
>
> If the mixing of configuration/setup with writing/reading bothers you,
> then I would suggest using two methods. One that does only the
> writing/reading assuming a limited API, and another that does the
> configuration/setup, using composition.
>
> Note that the streams that you get already are a composition (most often a
> BinaryFileStream wrapped in a Buffered stream wrapped in a
> Encoding/Decoding stream). EOL translation is not a standard part of that.
> But there is quite some system code that does uses EOL translation.
>
> Sven
>
>
>
>

Re: [Pharo-users] Calypso - can we improve the bar of radio buttons?

[Ben Coman]

On 25 June 2018 at 21:49, Tim Mackinnon  wrote:

> Hi - I don’t want to case a UI war, particularly as I was very impressed
> with Denis’ presentation about Calypso at the PharoDays conference last
> year.
>

I'm also very much enjoying Calypso.  Especially the multiple tabs for the
code pane
and being able to peak at the class definition half way through editing a
method.



> Now that I’ve made a concerted effort to try and use Calypso, and in
> general like it,  I do however find that the bar of Radio Buttons above the
> tabs is a bit overwhelming and I’m wondering if there might be something we
> can do to help make it less so?
>
> I’m sure the problem is the age old observation that a checkbox or button
> that toggles between states is difficult to understand whether its on or
> off and what the alternate state is - so this is why we now have a row of 8
> radio buttons.
>
> But 8 is a lot of radio buttons… which  I find visually hard to parse and
> often find the order of the buttons the opposite to what I expect - eg.
> When I want to see class methods I keep pausing over that group to see
> which one to click (for some reason I keep thinking the class one should be
> before the instance one - not sure if anyone else notices this).
>
> I’m also not overly keen on the terminology of “side” (as in class side,
> vs inst. side) and equally I question abbreviations like: Hier. Inst. Refs.
>
> Can we not just get rid of that bar completely - and put little icon
> buttons next to the filter field for pkg/project and flat/hierarchy ?
>

It would be interesting to see an experiment that replaced that bar with
tabs above each pane:
Pane 1:  [Packages][Projects] tabs
Pane 2:  [Flat][Hierarchy] tabs
Pane 3:  [Instance][Class] tabs**
Pane 4:  [Method][Variables] tabs

If 3[Instance] > 4[Variables] would show
  class-variables...
  instance-variables...

and 3[Class] > 4[Variables] would show
   class-variables...
   class-instance-variables...

this could help familiarize newcomers with the scope of these terms.

cheers -ben





> OR  given the method pane is now a tree and it already has an entry
> “instance side” - why not just have entries for “instance methods” and
> “class methods” and just expand accordingly? We also now have a tab “Inst.
> side method” - why not 2 tabs “+instance method” and “+class method”. It
> breaks a bit with regular smalltalk browser conventions - but I think
> Calypso has already pushed the boat out on all this anyway in favour of
> improved navigation and ease of typing code.
>
> My understanding is that this is all pretty doable with the mechanism
> Denis has put in place. I’m tempted to have a look, but thought I’d see
> what that general feeling is here, as maybe I’m on my own here.
>
> Tim
>

[Pharo-users] Some facts and figures about pharo gaining momentum?

[Andrei Stebakov]

Hi!

Do we as a community have some proofs in numbers that the popularity of
smalltalk grows?
I saw some articles that have some proofs that smalltalk is on the rise,
but for my presentation I'd like to back it up with some numbers if
possible.
You know, it's one thing when you preach to the choir but quite another
when you talk to some die-hard Java or JavaScript devs!
Any ideas about some great convincing material is also very welcome!

Re: [Pharo-users] Calypso - how do you revert unsaved changes?

[Tim Mackinnon]

A - mouse blindness - glad you pointed that out, it was driving me batty.



> On 25 Jun 2018, at 14:03, Cyril Ferlicot D.  wrote:
> 
> On 25/06/2018 14:48, Tim Mackinnon wrote:
>> Hi - in Calypso in Pharo 7, there is a neat concept of method changes that 
>> are yet saved (and the top right of the editor has the normal orange smudge 
>> indicator).
>> 
>> I like the idea (which lets you naviaged elsewhere to check something before 
>> making your change) - however if you want to revert that change and just go 
>> back to the original source - how do you do this?
>> 
>> There is a little X indicator in the status bar - but that seems to do 
>> nothing (?).
>> 
> 
> Hi,
> 
> In the context menu there is a "cancel" option with the Ctrl + L shortcut.
> 
>> Do you have to use the versions menu and pick revert? But then when I do 
>> that - I see a Red smudge on the text pane now, and the method source hasn’t 
>> reverted? So I’m a bit confused what you are supposed to do? The closes I 
>> can get to - is closing the tab in the browser and then reclick on the 
>> method in question - but I’m wondering if I’m missing an obvious alternative?
>> 
>> Tim
>> 
>> 
> 
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 

[Pharo-users] Calypso - can we improve the bar of radio buttons?

[Tim Mackinnon]

Hi - I don’t want to case a UI war, particularly as I was very impressed with 
Denis’ presentation about Calypso at the PharoDays conference last year.

Now that I’ve made a concerted effort to try and use Calypso, and in general 
like it,  I do however find that the bar of Radio Buttons above the tabs is a 
bit overwhelming and I’m wondering if there might be something we can do to 
help make it less so?

I’m sure the problem is the age old observation that a checkbox or button that 
toggles between states is difficult to understand whether its on or off and 
what the alternate state is - so this is why we now have a row of 8 radio 
buttons. 

But 8 is a lot of radio buttons… which  I find visually hard to parse and often 
find the order of the buttons the opposite to what I expect - eg. When I want 
to see class methods I keep pausing over that group to see which one to click 
(for some reason I keep thinking the class one should be before the instance 
one - not sure if anyone else notices this).

I’m also not overly keen on the terminology of “side” (as in class side, vs 
inst. side) and equally I question abbreviations like: Hier. Inst. Refs.

Can we not just get rid of that bar completely - and put little icon buttons 
next to the filter field for pkg/project and flat/hierarchy ?

OR  given the method pane is now a tree and it already has an entry “instance 
side” - why not just have entries for “instance methods” and “class methods” 
and just expand accordingly? We also now have a tab “Inst. side method” - why 
not 2 tabs “+instance method” and “+class method”. It breaks a bit with regular 
smalltalk browser conventions - but I think Calypso has already pushed the boat 
out on all this anyway in favour of improved navigation and ease of typing code.

My understanding is that this is all pretty doable with the mechanism Denis has 
put in place. I’m tempted to have a look, but thought I’d see what that general 
feeling is here, as maybe I’m on my own here.

Tim

Re: [Pharo-users] Iceberg - finding deleted classes, reverting versions?

[Ben Coman]

On 25 June 2018 at 19:41, Tim Mackinnon  wrote:

> I’d be really interested if someone with lower level GIT knowledge might
> try a:
>
> git checkout  src//.class.st
> 
>
> For their project - as I don’t understand what I’m doing wrong - and I’d
> like the comfort of knowing that our source is in a place/state where we
> can rely on normal git tools in a case of emergency. At the moment, I’m a
> bit nervous that we are corrupting something .
>
> Tim
>

I'm not sure if this is what you wanted, but I found a test case for for
Pharo 7, a deleted class "MultiByteFileStreamTest.class.st"
https://github.com/pharo-project/pharo/pull/1031/files#diff-750a25fb99d29cda8c2c388dc18f6c1cL1

>From Windows 10 cmd.exe I tried the following (I can't remember which tool
installed `git`)...

> mkdir C:\temp\test
> cd C:\temp\test
> git clone g...@github.com:pharo-project/pharo.git
> cd pharo\src\Deprecated70
> dir  Multi*
no result
> git checkout e74308e67d9f84 MultiByteFileStreamTest.class.st
> dir Multi*
MultiByteFileStreamTest.class.st

Then I compared the file I checked out to the raw file on github and they
were identical...
https://www.diffchecker.com/gVCpJzFe


btw, I did get a momentary error "error: pathspec 'src/Deprecated70/
MultiByteFileStreamTest.class.st' did not match any file(s) known to git."
when I incorrectly did...
> cd pharo\src\Deprecated70
> git  git checkout e74308e67d9f84  src/Deprecated70/
MultiByteFileStreamTest.class.st


This worked with the longer path...
> cd pharo
> git  git checkout e74308e67d9f84  src/Deprecated70/
MultiByteFileStreamTest.class.st

cheers -ben

Re: [Pharo-users] Calypso - how do you revert unsaved changes?

[Cyril Ferlicot D.]

On 25/06/2018 14:48, Tim Mackinnon wrote:
> Hi - in Calypso in Pharo 7, there is a neat concept of method changes that 
> are yet saved (and the top right of the editor has the normal orange smudge 
> indicator).
> 
> I like the idea (which lets you naviaged elsewhere to check something before 
> making your change) - however if you want to revert that change and just go 
> back to the original source - how do you do this?
> 
> There is a little X indicator in the status bar - but that seems to do 
> nothing (?).
> 

Hi,

In the context menu there is a "cancel" option with the Ctrl + L shortcut.

> Do you have to use the versions menu and pick revert? But then when I do that 
> - I see a Red smudge on the text pane now, and the method source hasn’t 
> reverted? So I’m a bit confused what you are supposed to do? The closes I can 
> get to - is closing the tab in the browser and then reclick on the method in 
> question - but I’m wondering if I’m missing an obvious alternative?
> 
> Tim
> 
> 


-- 
Cyril Ferlicot
https://ferlicot.fr

[Pharo-users] Calypso - how do you revert unsaved changes?

[Tim Mackinnon]

Hi - in Calypso in Pharo 7, there is a neat concept of method changes that are 
yet saved (and the top right of the editor has the normal orange smudge 
indicator).

I like the idea (which lets you naviaged elsewhere to check something before 
making your change) - however if you want to revert that change and just go 
back to the original source - how do you do this?

There is a little X indicator in the status bar - but that seems to do nothing 
(?).

Do you have to use the versions menu and pick revert? But then when I do that - 
I see a Red smudge on the text pane now, and the method source hasn’t reverted? 
So I’m a bit confused what you are supposed to do? The closes I can get to - is 
closing the tab in the browser and then reclick on the method in question - but 
I’m wondering if I’m missing an obvious alternative?

Tim

Re: [Pharo-users] Iceberg - finding deleted classes, reverting versions?

[Tim Mackinnon]

I’d be really interested if someone with lower level GIT knowledge might try a:

git checkout  src//.class.st 
 

For their project - as I don’t understand what I’m doing wrong - and I’d like 
the comfort of knowing that our source is in a place/state where we can rely on 
normal git tools in a case of emergency. At the moment, I’m a bit nervous that 
we are corrupting something .

Tim


> On 22 Jun 2018, at 01:39, Tim Mackinnon  wrote:
> 
> Just to add more information to this - I did try what was suggested here (it 
> refers to a branch and not a commit id - but heck worth a shot) 
> https://stackoverflow.com/questions/5989592/git-cannot-checkout-branch-error-pathspec-did-not-match-any-files-kn
>  
> 
>  - but nah /refs/heads/src… or /origin/src… didn’t seem to give a recognised 
> path.
> 
> Grasping at straws I also tried --ignore-skip-worktree-bits 
> 
> So I’m really curious if anyone else has managed to restore a deleted Pharo 
> class in git?
> 
> Tim
> 
>> On 21 Jun 2018, at 16:07, Tim Mackinnon > > wrote:
>> 
>> Guille - just following up on this thread as I’d like to get more confident 
>> with this stuff.
>> 
>> You mentioned a Calypso plugin for versions - where is that? I loaded a 
>> recentish P7 image and I don’t see those icons? Is this something I can 
>> easily load to try out?
>> 
>> As I don’t have that plugin, I’ve followed up on your next suggestion (just 
>> to learn how to do this) about looking up a commit having used the command 
>> line git history to list all of my deleted classes (I think this might be a 
>> useful thing to add to Iceberg BTW).
>> 
>> Not sure how to get a repository but I cobbled together the following?
>> 
>> (IceLibgitRepository registry detect: [ :r | r name beginsWith: 'Prismic' ]) 
>> lookupCommit: '65363ad’.
>> 
>> This give me an IceGitCommit - but then what can I easily do with this to 
>> try and iterate over deleted classes to try and get the one I’ve identified 
>> back?
>> 
>> Failing all of this - I went back to the command line again (which should 
>> work) - and I’m really wondering if we do something weird with files or 
>> paths when checking in?
>> 
>> Having got a valid commitID (I used: git log --diff-filter=D --summary 
>> —pretty="format:%cd|%h|%cn%n%s%n” )
>> 
>> if I simply run the following (with the id and pathname taken from the 
>> output of my previous command
>> 
>> git checkout 65363ad src/PrismicDemo/PrismicBlock.class.st 
>> 
>> 
>> I keep getting an error : error: pathspec 
>> ‘src/PrismicDemo/PrismicBlock.class.st ' did 
>> not match any file(s) known to git. 
>> 
>> Are you able to confirm if you can restore a deleted class from a commit? 
>> I’ve tried it on 2 different OSX machines and neither of them works - making 
>> me think we do something odd.
>> 
>> Tim
>> 
>>> On 14 Jun 2018, at 08:52, Guillermo Polito >> > wrote:
>>> 
>>> Hi,
>>> 
>>> Regarding history, right now we have a history browser implemented as a 
>>> Calypso plugin, that is open using context menu => history or the little 
>>> box button on the top right of the method pane (second button from the left 
>>> in the picture):
>>> 
>>> 
>>> 
>>> That button will nowadays only be shown if the method's package is linked 
>>> to an iceberg repository.
>>> Once you click it, you will have the entire history of the method.
>>> 
>>> 
>>> 
>>> With the possibility to install that version of the method (among others).
>>> 
>>> Now, regarding the recovery of deleted classes/methods, have you tried the 
>>> repository browser?
>>> Go to Iceberg, right click on a repository and select "Repository".
>>> You can there select a commit in history and then in the tabs below see the 
>>> diff between
>>>  - your current version and the selected commit
>>>  - the selected commit and its main parent
>>> 
>>> Of course any of these can be improved, but if you have concrete requests, 
>>> it is much easier :)
>>> 
>>> https://github.com/pharo-vcs/iceberg 
>>> 
>>> Guille
>>> 
>>> On Wed, Jun 13, 2018 at 11:22 PM Tim Mackinnon >> > wrote:
>>> Hi Sean - I tried it again, and it worked:
>>> 
>>> git log --full-history -- */PrismicBlock.class*
>>> 
>>> (I got my wildcard slightly wrong for tonel format) - although the beauty 
>>> of the one I gave was that it shows you all deleted classes (in case you 
>>> don’t know the name)
>>> 
>>> I’m still confused why I can’t checkout the deleted class though - damn you 
>>> git, for the cryptic error: : error: pathspec 
>>> 'PrismicDemo/PrismicBlock.class.st ' did not 
>>> match any file(s) known to git.
>>> 
>>> I was hoping a quick hack to iceberg might be to OSProcess a few choice 

Re: [Pharo-users] Pharo 7 streams API

[Herbert Vojčík]

Peter Uhnák wrote on 23. 6. 2018 15:39:

Hi,

I'm starting to familiarize myself with new streams, and one thing I've 
noticed is the removal of #lineEndConvention (which I use all the time).


So a statement like this

aFile writeStreamDo: [ :stream |
stream lineEndConvention: #lf.
stream << '...'> ].

has to be written like so

aFile writeStreamDo: [ :rawStream | |stream|
stream := (ZnNewLineWriterStream on: rawStream) forLf.
stream << '...'
].

which feels very messy because I am mixing writing with the 
configuration. And I don't even take account for buffered/encoded 
decorators. Plus it increases the incidental complexity -- I need 
another variable, and I can accidentally write to the wrong stream, etc.


Would a method like #writeStream:do: (or #writeStreamTransform:do:) make 
sense? E.g.


aFile writeStreamTransform: [ :stream | (ZnNewLineWriterStream on: 
stream) ] do: [ :stream |

stream << '...'
]


  aFile writeStreamDo: [ :rawStream |
(ZnNewLineWriterStream on: rawStream) in: [ :stream |
  stream << '...' ] ].

As for transformation, I'd go for some more generic (functional?) 
approach like:


  aFile writeStreamDo: ([:x | ZnNewLineWriterStream on: x] pipe: [ 
:stream |

stream << '...' ]).

Herby


To separate the composition from the usage?

Thanks,
Peter

Re: [Pharo-users] Pharo 7, Iceberg, Proxy and Windows

[Guillermo Polito]

Hi Vitor,

I've created an issue with your problem.

https://github.com/pharo-vcs/iceberg/issues/885

I encourage you to do so too, because following the mailing list is
sometimes hard :)

About your second issue, you should know that libgit (
libgit2.github.com/libgit2) will mostly bypass git and reimplement most of
its features.
So, most of the times it will read git's settings, and some other times not.
And also there is the possibility that Iceberg overrides those settings too.

For example, your fix

*self prim_fetch_opts prim_proxy_opts prim_type: LGitProxyTypeEnum
git_proxy_auto*

does enable automatic proxy verification and forbids people to set their
own proxy.
Not saying that this is bad but the contrary: I think it is a really good
default value :).

Similar to that there are the ssh verifications on Iceberg. So far
 - we do not check the certificate stores from the machine (we could
through FFI, the sub-project is listed in here
https://github.com/pharo-vcs/iceberg/wiki/How-to-help-us,-What-you-could-contribute
)
 - I don't think so far there is a hook to "disable ssh verification". This
could be dangerous...

I've googled the error a bit, and found this. Maybe you can try it and see
wether the solution belongs to iceberg, or that we should enhance the
documentation?

https://stackoverflow.com/questions/48985995/gitkraken-and-github-failed-to-get-server-certificate-the-handle-is-in-the-wr

Tx,
Guille

On Thu, Jun 21, 2018 at 5:49 PM Vitor Medina Cruz 
wrote:

> I am sorry, the correct message is "LGit_GIT_ERROR: failed to get server
> certificate: The handle is in the wrong state for the requested operation".
>
>
> I tried to add corporate certificates to the git curl-ca-bundle.crt, I
> tried to git config --global http.sslVerify false also, no success... :(
>
> On Thu, Jun 21, 2018 at 9:31 AM, Vitor Medina Cruz 
> wrote:
>
>> Ok, I forgot to mention I have changed
>> LGitRepository>>clone:url:local_path:options:, but for some odd reason it's
>> arguments names were switched to arg 1, arg2, arg3 etc, so the out error
>> was because was renamed to one of those generic arg names. I figure that
>> out looking at the versions of the methods, and it apers that when I first
>> access it this change is made.
>>
>> Anyways, I fixed that and I still get "IceGenericError: failed to get
>> server certificate: The identifier is not in the correct state for the
>> resquested operation"
>>
>> On Wed, Jun 20, 2018 at 4:49 PM, Vitor Medina Cruz 
>> wrote:
>>
>>> Hello,
>>>
>>> Iceberg fail to function behind a proxy on Pharo 7 32bits Windows. When
>>> I try to clone I get a:
>>>
>>> IceGenericError: failed to get server certificate: The identifier is not
>>> in the correct state for the resquested operation
>>>
>>> I had a similar problem some time ago with Pharo 6, in which I made a
>>> local hot fix after questioning here. The fix was to the LGitCloneOptions
>>> and LGitFetchOptions both at the initializeWithDefaults, currently this
>>> method on LGitCloneOptions is like this:
>>>
>>>
>>> initializeWithDefaults
>>> self withReturnHandlerDo: [
>>> self
>>> clone_init_options: self
>>> version: LGitOptionsVersionsEnum
>>> git_clone_options_version_1 ].
>>>
>>>
>>>
>>> *self prim_fetch_opts prim_proxy_opts prim_type: LGitProxyTypeEnum
>>> git_proxy_auto*
>>> The bold is the fix, but it should come first in the method:
>>>
>>> initializeWithDefaults
>>>
>>>
>>> *self prim_fetch_opts prim_proxy_opts prim_type: LGitProxyTypeEnum
>>> git_proxy_auto*self withReturnHandlerDo: [
>>> self
>>> clone_init_options: self
>>> version: LGitOptionsVersionsEnum
>>> git_clone_options_version_1 ].
>>>
>>>
>>> That way worked on Pharo 6, but now I got a:
>>>
>>> "FFIVariableNameNotFound: Could not find accessor for variable named
>>> 'out'"
>>>
>>> Any clues?
>>>
>>> Regards,
>>> Vitor
>>>
>>
>>
>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] OmniBase for Pharo 6

[PBKResearch]

Todd

 

Many thanks for these useful pointers – I had thought of asking you for a hint 
of where problems can occur, but you beat me to it. At present I am just 
playing, to get the feel of what it can do, but when it gets to real data I 
will consider defensive measures – backups and change logs, for example.

 

The application I am considering involves reading and storing quite large 
documents, which are input as XML. Presumably it would be safer to store the 
XML in the database. Similarly, with other complex objects, we could consider a 
hybrid system in which objects are serialized with some other mechanism, e.g. 
STON, and OmniBase is just used to store and manage them. All speculation until 
we try it out.

 

Thanks again

 

Peter Kenny

 

From: Pharo-users  On Behalf Of Todd 
Blanchard
Sent: 25 June 2018 07:31
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] OmniBase for Pharo 6

 

I will just add that the failures I was experiencing involved storing 
"documents" with deep hierarchies of heterogeneous items.  Something along the 
lines of EMR's (electronic medical records - which if you have any experience 
in that domain - are very complex).

 

The failures would manifest as randomly thrown exceptions while trying to read 
a particularly large and complex hierarchy - which would result in documents 
missing segments when rendered.  Rescuing the data took a couple weeks of 
constantly trying to read smaller chunks and retrying when exceptions were 
thrown.

 

So I would include tests along those lines before trusting it with important 
data.  The database I was working with was quite large when reads began to fail.

 

On Jun 24, 2018, at 3:33 PM, Matias Maretto mailto:mgmare...@hotmail.com> > wrote:

 

Thank you for the info Peter ; I have been working storing and retrieving data 
, everything works fine. I have an ODBPErsistDictionary with almost 20.000 
objects on it, I really get sorprised of how fast can resolve "select:[] 
commands"; I know it is not related with the subjet we are working, but well 

 

 

 


  _  


De: Pharo-users mailto:pharo-users-boun...@lists.pharo.org> > en nombre de PBKResearch 
mailto:pe...@pbkresearch.co.uk> >
Enviado: domingo, 24 de junio de 2018 05:54 p. m.
Para: 'Any question about pharo is welcome'
Asunto: Re: [Pharo-users] OmniBase for Pharo 6

 

Hi Matias (and EstebanLM)

 

I have explained the problem with storing and retrieving Date. Looking through 
the OmniBase code in the repository, I see that there is a whole series of 
extensions for many of the standard classes, which provide methods for 
serializing and deserializing instances of those classes. The extension for 
Date class ignores the start time, and simply saves the day number; the 
retrieval method can only use the days, and so cannot take account of the 
offset for the time zone. If it is necessary to save and restore dates in a way 
which is time-zone sensitive, it will be necessary to modify the code for 
serializing dates to store day and offset. I have not yet worked out how the 
methods are structured, so I have not tried to recode, but all the methods I 
have looked at are only one or two lines, so it should not be difficult.

 

Looking through the classes with extensions, I realise that we may need to 
check rather more examples to be sure that everything is handled correctly. I 
did one little test with String. The standard test in TestEquality just stores 
and retrieves ‘Hello World’. To check that it could handle other encodings, I 
tried the test with a German string encoded in utf8. This worked OK. So thus 
far everything is fine, but it would be a good idea to check correct retrieval 
each time we persist a new class of object.

 

Best wishes

 

Peter Kenny

 

From: Pharo-users mailto:pharo-users-boun...@lists.pharo.org> > On Behalf Of Matias Maretto
Sent: 23 June 2018 19:40
To: Any question about pharo is welcome mailto:pharo-users@lists.pharo.org> >
Subject: Re: [Pharo-users] OmniBase for Pharo 6

 

Hi Peter, thanks for the news. I have been doing some tests, persisting 
diferent kind of objects and until now everythings works fine.

If you find anything else, please let me now.

 

Thanks.

Matias.

 

 


  _  


De: Pharo-users mailto:pharo-users-boun...@lists.pharo.org> > en nombre de PBKResearch 
mailto:pe...@pbkresearch.co.uk> >
Enviado: sábado, 23 de junio de 2018 05:18 p. m.
Para: 'Any question about pharo is welcome'
Asunto: Re: [Pharo-users] OmniBase for Pharo 6

 

Hi Matias

 

A further report. I have worked through the test suite in OmniBaseTests, 
running each test individually. I now have all green except two – testEquality, 
which fails on the storage and retrieval of ‘Date today’, and testGC, which 
fails for reasons I have not yet found.

 

The worrying thing is the apparent change in the instance variables of Date – 
see my exchange with Alistair Grant in another thread. I shall try to work 
through the way 

Re: [Pharo-users] OmniBase for Pharo 6

[Todd Blanchard]

I will just add that the failures I was experiencing involved storing 
"documents" with deep hierarchies of heterogeneous items.  Something along the 
lines of EMR's (electronic medical records - which if you have any experience 
in that domain - are very complex).

The failures would manifest as randomly thrown exceptions while trying to read 
a particularly large and complex hierarchy - which would result in documents 
missing segments when rendered.  Rescuing the data took a couple weeks of 
constantly trying to read smaller chunks and retrying when exceptions were 
thrown.

So I would include tests along those lines before trusting it with important 
data.  The database I was working with was quite large when reads began to fail.

> On Jun 24, 2018, at 3:33 PM, Matias Maretto  wrote:
> 
> Thank you for the info Peter ; I have been working storing and retrieving 
> data , everything works fine. I have an ODBPErsistDictionary with almost 
> 20.000 objects on it, I really get sorprised of how fast can resolve 
> "select:[] commands"; I know it is not related with the subjet we are 
> working, but well 
> 
> 
> 
> 
> De: Pharo-users  > en nombre de PBKResearch 
> mailto:pe...@pbkresearch.co.uk>>
> Enviado: domingo, 24 de junio de 2018 05:54 p. m.
> Para: 'Any question about pharo is welcome'
> Asunto: Re: [Pharo-users] OmniBase for Pharo 6
>  
> Hi Matias (and EstebanLM)
>  
> I have explained the problem with storing and retrieving Date. Looking 
> through the OmniBase code in the repository, I see that there is a whole 
> series of extensions for many of the standard classes, which provide methods 
> for serializing and deserializing instances of those classes. The extension 
> for Date class ignores the start time, and simply saves the day number; the 
> retrieval method can only use the days, and so cannot take account of the 
> offset for the time zone. If it is necessary to save and restore dates in a 
> way which is time-zone sensitive, it will be necessary to modify the code for 
> serializing dates to store day and offset. I have not yet worked out how the 
> methods are structured, so I have not tried to recode, but all the methods I 
> have looked at are only one or two lines, so it should not be difficult.
>  
> Looking through the classes with extensions, I realise that we may need to 
> check rather more examples to be sure that everything is handled correctly. I 
> did one little test with String. The standard test in TestEquality just 
> stores and retrieves ‘Hello World’. To check that it could handle other 
> encodings, I tried the test with a German string encoded in utf8. This worked 
> OK. So thus far everything is fine, but it would be a good idea to check 
> correct retrieval each time we persist a new class of object.
>  
> Best wishes
>  
> Peter Kenny
>  
> From: Pharo-users  > On Behalf Of Matias Maretto
> Sent: 23 June 2018 19:40
> To: Any question about pharo is welcome  >
> Subject: Re: [Pharo-users] OmniBase for Pharo 6
>  
> Hi Peter, thanks for the news. I have been doing some tests, persisting 
> diferent kind of objects and until now everythings works fine.
> If you find anything else, please let me now.
>  
> Thanks.
> Matias.
>  
>  
> De: Pharo-users  > en nombre de PBKResearch 
> mailto:pe...@pbkresearch.co.uk>>
> Enviado: sábado, 23 de junio de 2018 05:18 p. m.
> Para: 'Any question about pharo is welcome'
> Asunto: Re: [Pharo-users] OmniBase for Pharo 6
>  
> Hi Matias
>  
> A further report. I have worked through the test suite in OmniBaseTests, 
> running each test individually. I now have all green except two – 
> testEquality, which fails on the storage and retrieval of ‘Date today’, and 
> testGC, which fails for reasons I have not yet found.
>  
> The worrying thing is the apparent change in the instance variables of Date – 
> see my exchange with Alistair Grant in another thread. I shall try to work 
> through the way OmniBase saves and resets the instvars, just in case it might 
> be a general problem.
>  
> I shall let you know of anything else I find.
>  
> Peter Kenny
>  
> From: Pharo-users  > On Behalf Of PBKResearch
> Sent: 23 June 2018 09:18
> To: 'Any question about pharo is welcome'  >
> Subject: Re: [Pharo-users] OmniBase for Pharo 6
>  
> Matias
>  
> Thanks. I have made this change, but it does not affect the tests I have run.
>  
> I have focused on getting the test suite in OmniBaseTests to run. So far I 
> still have 5 greens, 7 reds and one orange. The greens are all the first five 
> test methods in the browser list; it seems it half fails on the sixth one 
> (TestEquality), hence the orange, and then red for all the rest.
>  
> One problem is that the test database is created at the start of the