[Pharo-dev] Esteban’s list of blocking issues for release Pharo 6.0 (updated to May 08)

2017-05-08 Thread Esteban Lorenzano
Hello, 

This are the things I believe still needs to be solved to be able to release 
Pharo 6.0: 

PENDING:
- image: iceberg hit the image (dev-0.4 is ready to enter)
- remove all test regressions
- NEW: pharovm is crashing on 64bits
FIXED: (none)
POSPOSED: iceberg to use libgit2 0.25.1 (needed to compile it in 64bits, but 
not mandatory)

Release checklist: 

- Prepare release notes
Image:
- add welcome browser (ONGOING)
- generate PharoV60.sources (ONGOING)
- move SystemVersion
- prepare new ScriptLoader70 package (in theory, this will not needed anymore 
but better to have it as a backup :P)
VM:
- stable for 6.0 release (DONE)
WebSite:
- Update index
- Update download page
Infrastructure: 
- ZeroConf: Open new 7.0 development (ONGOING)
- SmalltalkCI: Open new 7.0 development (ONGOING)
- Create platform stable versions
- Jenkins: move all CI projects to Pharo 7.0 (ONGOING)
Pub:
- announce post
- announce mail
- post to YC, Reddit

I’m targeting this week for release. But you know how it is… it will happen 
most probably next monday ;)
Also, I don’t know what the problem with 64bits crashing is, I’m just starting 
to explore there… that can be a detail or a huge problem, and dince 64bits is 
“THE” important part of this release, is blocking enough to delay release.


Re: [Pharo-dev] Iceberg

2017-05-08 Thread Esteban Lorenzano

> On 8 May 2017, at 02:43, Ben Coman  wrote:
> 
> Until recently to work around a bug people were directed to "latest" vm.
> Now we are back to "stable"... http://files.pharo.org/vm/pharo-spur32/ 
> 

yes. 
and please, people… note that using “stable” should be the regular way. 
we were using latest because we are so unstable that we needed to (and I cannot 
ensure we will not have other periods like that). But in general, users not 
trying to fix something on the edge, need to stay with the stable.

cheers!
Esteban

> 
> cheers -ben
> 
> On Mon, May 8, 2017 at 2:32 AM, Myroslava Romaniuk  
> wrote:
>> Which one is the stable VM then?
>> 
>> On 7 May 2017 21:07, "Esteban Lorenzano"  wrote:
>>> 
>>> are you trying VM latest?
>>> because you should use the stable now :)
>>> 
>>> I explain: I updated the latest VM to libgit2 0.25.1. While this works on
>>> most of my cases, I spotted this problem too.
>>> 
>>> cheers,
>>> Esteban
>>> 
>>> On 7 May 2017, at 18:40, Myroslava Romaniuk  wrote:
>>> 
>>> I am also trying to clone a repository and for me the command causes the
>>> following error: LGit_GIT_ERROR: error authenticating: failed connecting
>>> agent. I am using the latest image (60482) on Win 7 (64 bit).
>>> 
>>> On 7 May 2017 at 19:06, Elhamer  wrote:
 
 EstebanLM wrote
>> Yes, there is a bug now in iceberg (I will fix it soon), for now you
>> can
 go with:
> 
>> IceRepository defaultBackendType: #IceLibgitLocalRepository.
 
 
 This actually causes an Assertion failure, then a total crash:
 ---
 Microsoft Visual C++ Runtime Library
 ---
 Assertion failed!
 
 Program: ...
 File: e:/workspace/PharoVM-spur32/Architecture.../remote.c
 Line: 430
 
 Expression: out && repo && name
 
 For information on how your program can cause an assertion
 failure, see the Visual C++ documentation on asserts
 
 (Press Retry to debug the application - JIT must be enabled)
 ---
 Abort   Retry   Ignore
 ---
 
 I am using the image #60480 on a Windows 10 64bits OS
 
 
 
 
 
 
 --
 View this message in context:
 http://forum.world.st/Iceberg-tp4945776p4945804.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.
 
>>> 
>>> 
>>> 
>>> --
>>> З повагою,
>>> Мирослава Романюк.
>>> 
>>> 
>> 
> 



Re: [Pharo-dev] Anyone meeting up night before Pharo Days (17th?)

2017-05-08 Thread Tim Mackinnon
It sounds like there will at least be a few of us around wanting a beer - so 
maybe we can pick a venue and agree to meet up? I think it will be too late for 
me to eat (so I’ll have something on the train), but it would be nice to share 
a few beers and get caught up with what’s what, in preparation for Thurs.

Tim

> On 7 May 2017, at 18:59, Stephan Eggermont  wrote:
> 
> On 06/05/17 12:58, Tim Mackinnon wrote:
>> Hi guys - I managed to get a “weeknight pass” so that I can come to
>> Pharo days and try and catch up with all the progress you have made.
>> 
>> I’m taking a Eurostar on Wed night (17th) and wondering if anyone is
>> meeting up the night before on the 17th? I don’t arrive until 8:30 -
>> but maybe some of you are having some post supper drinks somewhere?
> 
> Yes, good idea. I'll arrive with a TGV from CDG at 21:11
> 
>> I have booked a hotel near the venue, but I’m thinking that I may
>> change it, to somewhere in town as I think it might make more sense
>> as I’m sure folks may end up eating in town anyway.
> 
> I haven't booked a hotel yet. I'll go for in-town.
> 
> Stephan
> 
> 
> 
> 
> 




[Pharo-dev] FileReference>>=

2017-05-08 Thread Alistair Grant
Hi All,

The current definition of FileReference>>= returns false if two 
instances point to the same location, but one is relative and the other 
is absolute, e.g.:


| f1 f2 |

f1 := FileLocator workingDirectory / 'pharo-local'.
f2 := f1 asAbsolute.
f1 = f2
"false"


This definition seems unintuitive to me as I'd expect this to be true 
since they are both pointing to the same file/directory.

This introduces unexpected behaviour, e.g. I currently have two entries 
in Iceberg pointing to the same local git repository as one was added 
with a relative file reference, while the other was added with an 
absolute file reference.

Apart from the potential to introduce problems by changing the 
definition, are there any arguments in favour of keeping the current 
definition?

What do you think of changing the definition (in Pharo 7)?

P.S. If we decide not to change it, then 
IceRepository>>checkForRegistryConflicts should be modified to compare 
absolute paths.


Thanks,
Alistair




[Pharo-dev] (Iceberg?) Merge compiles copies of trait methods in user classes

2017-05-08 Thread Aliaksei Syrel
Hi,

Time to time I notice that suddenly Trait methods are copied to user
classes. And now I realised that this happens as the result of merge even
if there are no differences in that particular Trait. Sometimes I manage to
notice new methods in changes window but sometimes not, and then after
months it is extremely difficult to find bugs related to copied methods,
because I may change Trait code expecting that it will be updated in all
users of that trait...

Unfortunately I don't have a testcase that reproduces this issue.. sorry..
Just wanted to let you know, maybe it is something that can be fixed before
release...

Cheers,
Alex


[Pharo-dev] Adding class side inst.var to a class using Trait results in nil message sent

2017-05-08 Thread Aliaksei Syrel
Hi,

Screenshot tells everything :)
I was trying to add "asdasd" inst var

[image: Inline images 1]

Cheers,
Alex


[Pharo-dev] [ann] bloc & cairo+morphic

2017-05-08 Thread Tudor Girba
Hi,

We are happy to announce that based on the work of Glenn, Alex extended Bloc 
(Sparta) to work directly in the Morphic world using Cairo as a backend.

Cairo is less powerful than Moz2D (see the screenshot below for an example), 
but the implementation addresses a concern that the community raised regarding 
a perceived increased liability due to the dependency to Moz2D. Essentially 
this means that Bloc can be treated as another graphical library that can 
coexist with Morphic without requiring any external VM plugin.



I would also like to point out that adding a new backend and host was possible 
because of the many iterations (including throwing away whole implementations) 
that Alex and Glenn went through. I think they did an amazing job.

You can find a bit more details about Bloc here:
http://www.humane-assessment.com/blog/bloc-flexible-backends-hosts/

Another issue raised regarding Bloc was that of the engineering effort required 
to make it a reality. That is why I would also like to announce that Alex 
joined feenk.com where he is primarily working on the graphical stack for Pharo.

Cheers,
Doru


--
www.tudorgirba.com
www.feenk.com

"To lead is not to demand things, it is to make them happen."






Re: [Pharo-dev] [ann] bloc & cairo+morphic

2017-05-08 Thread Ignacio Sniechowski
Doru,
This is great news! Thanks for sharing.
Cheers
Nacho

*Lic. Ignacio Sniechowski, MBA*
*Prosavic SRL*
☎*  (5411) 4542-6712*
📱* (54911) 6749-4721*




















On Mon, May 8, 2017 at 6:00 PM, Tudor Girba  wrote:

> Hi,
>
> We are happy to announce that based on the work of Glenn, Alex extended
> Bloc (Sparta) to work directly in the Morphic world using Cairo as a
> backend.
>
> Cairo is less powerful than Moz2D (see the screenshot below for an
> example), but the implementation addresses a concern that the community
> raised regarding a perceived increased liability due to the dependency to
> Moz2D. Essentially this means that Bloc can be treated as another graphical
> library that can coexist with Morphic without requiring any external VM
> plugin.
>
>
> I would also like to point out that adding a new backend and host was
> possible because of the many iterations (including throwing away whole
> implementations) that Alex and Glenn went through. I think they did an
> amazing job.
>
> You can find a bit more details about Bloc here:
> http://www.humane-assessment.com/blog/bloc-flexible-backends-hosts/
>
> Another issue raised regarding Bloc was that of the engineering effort
> required to make it a reality. That is why I would also like to announce
> that Alex joined feenk.com where he is primarily working on the graphical
> stack for Pharo.
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "To lead is not to demand things, it is to make them happen."
>
>
>
>
>