Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

[Ben Coman]

On 22 May 2018 at 23:23, Tim Mackinnon  wrote:

> Hi - when trying out the new Iceberg with a bunch of developers and
> explaining the challenges of integrating git and files into a smalltalk
> realm of the image - there was a lot of interest in how this works.
>
> When you clone - you obviously see a series of files (in Tonel - nice)
> that are then brought into your image. If you edit a file like Readme.md
> (using a markdown editor) you will notice that git status will show you
> that this file has changed. However if you then edit some methods - and
> then look in the file system - git status doesn’t show these? This in
> retrospect possibly feels weird - or does it? I’m not sure anymore - and
> was wondering if there was a specific reason behind not mirroring code
> changes back to the file system as they happen?
>

I guess the conceptual model they have might be of Pharo as a text editor
directly changing the files.
Its interesting to consider how that would operate.  Changes are
immediately reflected in Epcia files,
and used to be immediately written to ".changes" file, so it seems possible.

More interesting is what to do if the text file is edited outside Pharo.
If Pharo could observe this and then recompile the new file,
we might suddenly have a workable "external editor" workflow,
lack of which is a common complaint by some.

cheers -ben


>
> When you branch in Pharo, a command line git status does show that change
> - so some things clearly are being mirrored, just not code (Which I’m guess
> happens briefly when you click commit?).
>
> I’m curious now to understand the tradeoffs.
>
> Tim
>
> p.s. it is very nice for small private projects, to use a git client on
> your phone - edit a method or two on the train, commit your changes and
> then see your CI build the results and deploy a new website by the time you
> get off… yes its not the rich smalltalk environment for bigger changes -
> but tiny stuff, its quite nice to fallback on the traditional way.
>
>
>

Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

[Sean P. DeNigris]

Esteban A. Maringolo wrote
> there is no way to "save" the package other than committing its changes to
> the repo.

In the past, I sorely missed a feature like this. When Iceberg (or I!) was
confused about the state of the local repo/changes/whatever, I wished I had
a way to write to disk and then verify that it did "the right thing" and
manually fix with "normal" git tools if needed. Maybe Iceberg has improved
enough to make this unneeded…



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

Re: [Pharo-users] Pharo 7 - New Iceberg feedback

[Sean P. DeNigris]

Tim Mackinnon wrote
> Although possibly calling it “Commit…” might make it more obvious that you
> have a chance to review changes and change your mind

+1. This minor change would IMHO make things much more obvious, especially
to people unfamiliar with git…



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

Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

[Tim Mackinnon]

Actually I missed that one - thanks. Would have been a useful one to show 
everyone when we went through the commit process - it’s very good.

Sent from my iPhone



Sent from my iPhone
> On 22 May 2018, at 17:16, Sven Van Caekenberghe  wrote:
> 
> Partial answer, but you saw this, right ?
> 
> https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary
> 
>> On 22 May 2018, at 17:23, Tim Mackinnon  wrote:
>> 
>> Hi - when trying out the new Iceberg with a bunch of developers and 
>> explaining the challenges of integrating git and files into a smalltalk 
>> realm of the image - there was a lot of interest in how this works.
>> 
>> When you clone - you obviously see a series of files (in Tonel - nice) that 
>> are then brought into your image. If you edit a file like Readme.md (using a 
>> markdown editor) you will notice that git status will show you that this 
>> file has changed. However if you then edit some methods - and then look in 
>> the file system - git status doesn’t show these? This in retrospect possibly 
>> feels weird - or does it? I’m not sure anymore - and was wondering if there 
>> was a specific reason behind not mirroring code changes back to the file 
>> system as they happen?
>> 
>> When you branch in Pharo, a command line git status does show that change - 
>> so some things clearly are being mirrored, just not code (Which I’m guess 
>> happens briefly when you click commit?).
>> 
>> I’m curious now to understand the tradeoffs.
>> 
>> Tim
>> 
>> p.s. it is very nice for small private projects, to use a git client on your 
>> phone - edit a method or two on the train, commit your changes and then see 
>> your CI build the results and deploy a new website by the time you get off… 
>> yes its not the rich smalltalk environment for bigger changes - but tiny 
>> stuff, its quite nice to fallback on the traditional way.
> 
> 

Re: [Pharo-users] Pharo 7 - New Iceberg feedback

[Tim Mackinnon]

The community has invested a lot in a new way of working - I’ve seen the pain, 
but I think it’s both inspiring , a difficult journey but ultimately well worth 
it.

We need to finish this first leg though, but I’m still very proud to be a 
smalltalker ...

Sent from my iPhone

> On 22 May 2018, at 16:18, Sven Van Caekenberghe  wrote:
> 
> Hi Tim,
> 
> Thanks for the detailed/constructive feedback. I am sure it will be helpful.
> 
> Sven
> 
>> On 22 May 2018, at 17:15, Tim Mackinnon  wrote:
>> 
>> Hi - last night we managed to explore the new contribution process as well 
>> as the new iceberg ui at the U.K. Smalltalk meetup last night.
>> 
>> Not many had seen it before so it was a good test run.
>> 
>> As an initial comment - we need to invest a small amount of time to get the 
>> right docs in places you expect them as not doing so undoes a lot of good 
>> work -  the Pharo main site that points to old contribution docs (and 
>> doesn’t reference the new ones) must be updated ASAP to keep energy high (we 
>> almost lost a few folks last night by going down the wrong path - 
>> fortunately Cyril piped up on Discord for me - phew).
>> 
>> Armed with the right steps it was straightforward - much easier than the 
>> older slices mechanism (that I never was comfortable with) - so HUGE thanks 
>> for that everyone!
>> 
>> As we worked through it, the more git seasoned folks were confused why git 
>> status in a terminal wasn’t really showing the same info as iceberg (I’ll 
>> put this in a separate thread to discuss, as it’s an interesting thought 
>> which I’m sure has lively discussion).
>> 
>> Anyway - the new UI does take some getting used to (personally I liked the 
>> compactness of the original Iceberg and its tabs), but when you understand 
>> what the different windows show you - I think it makes sense (and hopefully 
>> is more stable). We all missed having an obvious Diff mechanism - we later 
>> spotted that Commit does show this (Although possibly calling it “Commit…” 
>> might make it more obvious that you have a chance to review changes and 
>> change your mind) - but knowing the size of your change and reviewing them 
>> without any danger of committing something is a useful feature (but maybe a 
>> 2.0 enhancement request?).
>> 
>> One small tweak (which I would PR if I knew how to - would be to swap  the 
>> status and branch columns in the Repository window  to make the status  
>> clearer (the status gets lost as it sqashed against the normally much longer 
>> branch name).  Its a simple change to #initializeRepositoryList but I guess 
>> Iceberg is in a different repository (and not in the instructions for 
>> contirbutions).
>> 
>> We also noticed that if you try to use the “Create Pull Request” menu item, 
>> you can’t if you have 2FA enabled on Github (the recommended setting) as I 
>> guess that ssh protocol doesn’t allow this with an ssh key? So I we should 
>> update the instructions to suggest either using the web ui - or - creating 
>> an app specific login (that doesn’t use 2fa). - I’ll look at how to add that 
>> tweak and send a PR.
>> 
>> 
>> Tim
>> 
>> 
>> Sent from my iPhone
> 
> 

Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

[Esteban A. Maringolo]

I agree with you that it is weird, but as I understand it it is
because the process of "Saving" a package and "Committing" it is
merged into a single action, so there is no way to "save" the package
other than committing its changes to the repo.

This has the drawback you mentioned, but I guess this enables you to
simultaneously save the same package to more than one repository.

Maybe a diagram could make the whole picture more clear.

Regards,

Esteban A. Maringolo


2018-05-22 12:23 GMT-03:00 Tim Mackinnon :
> Hi - when trying out the new Iceberg with a bunch of developers and 
> explaining the challenges of integrating git and files into a smalltalk realm 
> of the image - there was a lot of interest in how this works.
>
> When you clone - you obviously see a series of files (in Tonel - nice) that 
> are then brought into your image. If you edit a file like Readme.md (using a 
> markdown editor) you will notice that git status will show you that this file 
> has changed. However if you then edit some methods - and then look in the 
> file system - git status doesn’t show these? This in retrospect possibly 
> feels weird - or does it? I’m not sure anymore - and was wondering if there 
> was a specific reason behind not mirroring code changes back to the file 
> system as they happen?
>
> When you branch in Pharo, a command line git status does show that change - 
> so some things clearly are being mirrored, just not code (Which I’m guess 
> happens briefly when you click commit?).
>
> I’m curious now to understand the tradeoffs.
>
> Tim
>
> p.s. it is very nice for small private projects, to use a git client on your 
> phone - edit a method or two on the train, commit your changes and then see 
> your CI build the results and deploy a new website by the time you get off… 
> yes its not the rich smalltalk environment for bigger changes - but tiny 
> stuff, its quite nice to fallback on the traditional way.
>
>

Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

[Sven Van Caekenberghe]

Partial answer, but you saw this, right ?

https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary

> On 22 May 2018, at 17:23, Tim Mackinnon  wrote:
> 
> Hi - when trying out the new Iceberg with a bunch of developers and 
> explaining the challenges of integrating git and files into a smalltalk realm 
> of the image - there was a lot of interest in how this works.
> 
> When you clone - you obviously see a series of files (in Tonel - nice) that 
> are then brought into your image. If you edit a file like Readme.md (using a 
> markdown editor) you will notice that git status will show you that this file 
> has changed. However if you then edit some methods - and then look in the 
> file system - git status doesn’t show these? This in retrospect possibly 
> feels weird - or does it? I’m not sure anymore - and was wondering if there 
> was a specific reason behind not mirroring code changes back to the file 
> system as they happen?
> 
> When you branch in Pharo, a command line git status does show that change - 
> so some things clearly are being mirrored, just not code (Which I’m guess 
> happens briefly when you click commit?).
> 
> I’m curious now to understand the tradeoffs.
> 
> Tim
> 
> p.s. it is very nice for small private projects, to use a git client on your 
> phone - edit a method or two on the train, commit your changes and then see 
> your CI build the results and deploy a new website by the time you get off… 
> yes its not the rich smalltalk environment for bigger changes - but tiny 
> stuff, its quite nice to fallback on the traditional way.
> 
> 

[Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

[Tim Mackinnon]

Hi - when trying out the new Iceberg with a bunch of developers and explaining 
the challenges of integrating git and files into a smalltalk realm of the image 
- there was a lot of interest in how this works.

When you clone - you obviously see a series of files (in Tonel - nice) that are 
then brought into your image. If you edit a file like Readme.md (using a 
markdown editor) you will notice that git status will show you that this file 
has changed. However if you then edit some methods - and then look in the file 
system - git status doesn’t show these? This in retrospect possibly feels weird 
- or does it? I’m not sure anymore - and was wondering if there was a specific 
reason behind not mirroring code changes back to the file system as they happen?

When you branch in Pharo, a command line git status does show that change - so 
some things clearly are being mirrored, just not code (Which I’m guess happens 
briefly when you click commit?).

I’m curious now to understand the tradeoffs.

Tim

p.s. it is very nice for small private projects, to use a git client on your 
phone - edit a method or two on the train, commit your changes and then see 
your CI build the results and deploy a new website by the time you get off… yes 
its not the rich smalltalk environment for bigger changes - but tiny stuff, its 
quite nice to fallback on the traditional way.

Re: [Pharo-users] Pharo 7 - New Iceberg feedback

[Sven Van Caekenberghe]

Hi Tim,

Thanks for the detailed/constructive feedback. I am sure it will be helpful.

Sven

> On 22 May 2018, at 17:15, Tim Mackinnon  wrote:
> 
> Hi - last night we managed to explore the new contribution process as well as 
> the new iceberg ui at the U.K. Smalltalk meetup last night.
> 
> Not many had seen it before so it was a good test run.
> 
> As an initial comment - we need to invest a small amount of time to get the 
> right docs in places you expect them as not doing so undoes a lot of good 
> work -  the Pharo main site that points to old contribution docs (and doesn’t 
> reference the new ones) must be updated ASAP to keep energy high (we almost 
> lost a few folks last night by going down the wrong path - fortunately Cyril 
> piped up on Discord for me - phew).
> 
> Armed with the right steps it was straightforward - much easier than the 
> older slices mechanism (that I never was comfortable with) - so HUGE thanks 
> for that everyone!
> 
> As we worked through it, the more git seasoned folks were confused why git 
> status in a terminal wasn’t really showing the same info as iceberg (I’ll put 
> this in a separate thread to discuss, as it’s an interesting thought which 
> I’m sure has lively discussion).
> 
> Anyway - the new UI does take some getting used to (personally I liked the 
> compactness of the original Iceberg and its tabs), but when you understand 
> what the different windows show you - I think it makes sense (and hopefully 
> is more stable). We all missed having an obvious Diff mechanism - we later 
> spotted that Commit does show this (Although possibly calling it “Commit…” 
> might make it more obvious that you have a chance to review changes and 
> change your mind) - but knowing the size of your change and reviewing them 
> without any danger of committing something is a useful feature (but maybe a 
> 2.0 enhancement request?).
> 
> One small tweak (which I would PR if I knew how to - would be to swap  the 
> status and branch columns in the Repository window  to make the status  
> clearer (the status gets lost as it sqashed against the normally much longer 
> branch name).  Its a simple change to #initializeRepositoryList but I guess 
> Iceberg is in a different repository (and not in the instructions for 
> contirbutions).
> 
> We also noticed that if you try to use the “Create Pull Request” menu item, 
> you can’t if you have 2FA enabled on Github (the recommended setting) as I 
> guess that ssh protocol doesn’t allow this with an ssh key? So I we should 
> update the instructions to suggest either using the web ui - or - creating an 
> app specific login (that doesn’t use 2fa). - I’ll look at how to add that 
> tweak and send a PR.
> 
> 
> Tim
> 
> 
> Sent from my iPhone

[Pharo-users] Pharo 7 - New Iceberg feedback

[Tim Mackinnon]

Hi - last night we managed to explore the new contribution process as well as 
the new iceberg ui at the U.K. Smalltalk meetup last night.

Not many had seen it before so it was a good test run.

As an initial comment - we need to invest a small amount of time to get the 
right docs in places you expect them as not doing so undoes a lot of good work 
-  the Pharo main site that points to old contribution docs (and doesn’t 
reference the new ones) must be updated ASAP to keep energy high (we almost 
lost a few folks last night by going down the wrong path - fortunately Cyril 
piped up on Discord for me - phew).

Armed with the right steps it was straightforward - much easier than the older 
slices mechanism (that I never was comfortable with) - so HUGE thanks for that 
everyone!

As we worked through it, the more git seasoned folks were confused why git 
status in a terminal wasn’t really showing the same info as iceberg (I’ll put 
this in a separate thread to discuss, as it’s an interesting thought which I’m 
sure has lively discussion).

Anyway - the new UI does take some getting used to (personally I liked the 
compactness of the original Iceberg and its tabs), but when you understand what 
the different windows show you - I think it makes sense (and hopefully is more 
stable). We all missed having an obvious Diff mechanism - we later spotted that 
Commit does show this (Although possibly calling it “Commit…” might make it 
more obvious that you have a chance to review changes and change your mind) - 
but knowing the size of your change and reviewing them without any danger of 
committing something is a useful feature (but maybe a 2.0 enhancement request?).

One small tweak (which I would PR if I knew how to - would be to swap  the 
status and branch columns in the Repository window  to make the status  clearer 
(the status gets lost as it sqashed against the normally much longer branch 
name).  Its a simple change to #initializeRepositoryList but I guess Iceberg is 
in a different repository (and not in the instructions for contirbutions).

We also noticed that if you try to use the “Create Pull Request” menu item, you 
can’t if you have 2FA enabled on Github (the recommended setting) as I guess 
that ssh protocol doesn’t allow this with an ssh key? So I we should update the 
instructions to suggest either using the web ui - or - creating an app specific 
login (that doesn’t use 2fa). - I’ll look at how to add that tweak and send a 
PR.


Tim


Sent from my iPhone

Re: [Pharo-users] [TechTalk] TODAY, 17h: Pillar

[Marcus Denker]

> On 17 May 2018, at 15:44, Marcus Denker  wrote:
> 
> Hi,
> 
> Today, 17h europe time.
> 
> Pharo TechTalk: Pillar
>   https://association.pharo.org/event-2797069
> 
> Sorry for the late announcement (we did not know if we could make it today)
> 

The recording is available here: https://www.youtube.com/watch?v=cdi3Vz3oaAs 


I have updated the archive: https://pharo.org/TechTalk 


We are looking for someone who wants to take over the June TechTalk!

Marcus

Re: [Pharo-users] On UDP broadcast

[Henrik Sperre Johansen]

HilaireFernandes wrote
> Thanks Sven for the indications.
> 
> Of course I already looked at this Test, but I got lost. I looked at it 
> again, and wrote something like:
> 
> | socket data | socket := Socket newUDP. socket setPort: .
> socket waitForConnectionFor: 2; waitForDataFor: 5 . data := Array
> new: 100.     [socket receiveUDPDataInto: data.     data crLog]
> ensure: [ 'Closing socket' crLog. socket closeAndDestroy]
> 
> I do not have error, but a time out.
> 
> Dr. Geo
> http://drgeo.eu

With UDP, there is no connection concept, so I'd reckon
waitForConnectionFor: is what gives you a TimeOut error...

Delete that, only use waitForDataFor: n , put it in a loop (so it won't stop
listening until it receives a request), and you should be fine.

Doesn't quite look like neither server nor client yet, the workflow should
be something like:
1) server (you) starts, listening to port you're using and waitsForData: in
an infinite loop.
2) client (student) starts, sends request to broadcast address/port, then
waitsForData: on the socket it created.
3) broadcast server reads request, generates reply, and sends it to the
originIP/port of the request
4) client receives reply, handles it, and closes socket.

Cheers,
Henry

PS. Why use nc when you already have a working broadcast client in pharo? ;)



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

Re: [Pharo-users] [Pharo-dev] LibFFI/NB Cairo External Module Not Found debugging

[Esteban Lorenzano]

why libcairo2-dev and not just libcairo2?

cheers,
Esteban

> On 21 May 2018, at 17:25, Richard O'Keefe  wrote:
> 
> Thank you for that.  The instructions there are incomplete.
> It is necessary to add
> sudo apt-get install libcairo2-dev:i386
> to the script.
> 
> On 21 May 2018 at 19:36, John Pfersich  > wrote:
> If you are running a 32 bit Pharo on a 64 bit Ubuntu, there is instructions 
> for additional steps needed at https://pharo.org/gnu-linux-installation 
>  under the ‘Prepare 64-bit-Linux 
> for 32bit Pharo’ heading
> 
> For encrypted mail use jgpfers...@protonmail.com 
> 
> Get a free account at ProtonMail.com 
> Web: www.objectnets.net  and www.objectnets.org 
> 
> 
> On May 21, 2018, at 00:18, Richard O'Keefe  > wrote:
> 
>> It's not just Windows users.  I have Pharo 6.0 #605.40
>> running under Linux Ubuntu version 17.10 and the cairo
>> library is definitely installed.
>> 
>> Just starting Pharo is a little concerning:
>> ok@Herbrand:~/Smalltalk$ pharo
>> ioLoadModule(/home/ok/Pharo.d/pharo-vm/lib/pharo/5.0-201707201942/FT2Plugin.so):
>>   libfreetype.so.6: cannot open shared object file: No such file or directory
>> ioLoadModule(/home/ok/Pharo.d/pharo-vm/lib/pharo/5.0-201707201942/FT2Plugin.so):
>>   libfreetype.so.6: cannot open shared object file: No such file or directory
>> Yet these files exist.
>> /usr/lib/x86_64-linux-gnu/libfreetype.a
>> /usr/lib/x86_64-linux-gnu/libfreetype.so
>> /usr/lib/x86_64-linux-gnu/libfreetype.la 
>> /usr/lib/x86_64-linux-gnu/libfreetype.so.6
>> /usr/lib/x86_64-linux-gnu/libfreetype.so.6.14.0
>> 
>> When I try any Roassal examples, I get
>> Error: cannot locate cairo library. Please check if it is installed ...
>> CairoLibrary(Object) error:
>> CairoLibrary unix32ModuleName
>> Unix32Platform ffiModuleName
>> CairoLibrayr(FFILibrary) moduleName
>> FFICalloutMethodBuilder moduleName
>> 
>> The 32 is the clue.  Apparently I'm running a 32-bit Pharo
>> with 64-bit libraries installed.  Could this be the problem
>> on Windows?
>> 
>> 
>> On 21 May 2018 at 07:46, Guillermo Polito > > wrote:
>> 
>> 
>> On Sat, May 19, 2018 at 1:37 PM, Peter Uhnák > > wrote:
>> Hi,
>> 
>> some Windows users are repeatedly running into Pharo failing to load Cairo 
>> library on Windows (see stack screenshot at the bottom).
>> 
>> The problem is that I have no idea how to even start debugging this.
>> 
>> Is there some documentation on how Pharo loads libraries via FFI on Windows 
>> that I can start digging into?
>> 
>> Note that the library is definitely present, as this happens only 
>> occasionally -- it can be fixed by restarting PC. But I cannot reasonably 
>> ask users to restart just because Pharo decided it doesn't feel like loading 
>> a library.
>> 
>> Any pointers / docs / ideas appreciated.
>> 
>> You can see the actual code from 
>> 
>> https://github.com/OpenSmalltalk/opensmalltalk-vm/search?utf8=%E2%9C%93=findAndLoadModule%28char+*pluginName%2C+sqInt+ffiLoad%29=
>>  
>> 
>> 
>> ?
>>  
>> 
>> Thanks,
>> Peter
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>>
>> 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
>> 
>