context mirror primitives
Hi, The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo: object: anObject basicAt: index object: anObject basicAt: index put: value object: anObject eqeq: anOtherObject object: anObject instVarAt: anIndex object: anObject instVarAt: anIndex put: aValue object: anObject perform: selector withArguments: argArray inClass: lookupClass objectClass: anObject objectSize: anObject I added an issue and the slice: https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides. I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods? Cheers, Doru -- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."
Hello, This is unrelated to Spur / SqueakV3 memory manager. The VM support has been there and stable for a long time now. I tried to add those primitives in Pharo but the problem is that the debugger in Pharo uses EyeInspector whereas the inspectors are done with Glamour. Hence, to add support for ProtoObject debugging you need: - to make interpretation implemented in Context compliant - to make EyeInspector compliant (for the inspector in the debugger) - to make GTInspector compliant. Cheers ! Clement 2016-01-04 16:42 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo:
object: anObject basicAt: index object: anObject basicAt: index put: value object: anObject eqeq: anOtherObject object: anObject instVarAt: anIndex object: anObject instVarAt: anIndex put: aValue object: anObject perform: selector withArguments: argArray inClass: lookupClass objectClass: anObject objectSize: anObject
I added an issue and the slice:
https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides.
I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods?
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
Hi,
On Jan 4, 2016, at 6:30 PM, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
This is unrelated to Spur / SqueakV3 memory manager. The VM support has been there and stable for a long time now.
I tried to add those primitives in Pharo but the problem is that the debugger in Pharo uses EyeInspector whereas the inspectors are done with Glamour.
Hence, to add support for ProtoObject debugging you need: - to make interpretation implemented in Context compliant - to make EyeInspector compliant (for the inspector in the debugger) - to make GTInspector compliant.
I am not sure I understand what you mean by " interpretation implemented in Context compliantâ. Could you explain? I already made GTInspector and GTDebugger work with ProtoObject once. I lost the changes in the meantime :), but I will redo them. The only thing I needed were these primitives. But, maybe I missed something. Cheers, Doru
Cheers !
Clement
2016-01-04 16:42 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo:
object: anObject basicAt: index object: anObject basicAt: index put: value object: anObject eqeq: anOtherObject object: anObject instVarAt: anIndex object: anObject instVarAt: anIndex put: aValue object: anObject perform: selector withArguments: argArray inClass: lookupClass objectClass: anObject objectSize: anObject
I added an issue and the slice: https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides.
I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods?
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
-- www.tudorgirba.com www.feenk.com "Things happen when they happen, not when you talk about them happening."
Hi Doru,
On Jan 4, 2016, at 8:35 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Jan 4, 2016, at 6:30 PM, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
This is unrelated to Spur / SqueakV3 memory manager. The VM support has been there and stable for a long time now.
I tried to add those primitives in Pharo but the problem is that the debugger in Pharo uses EyeInspector whereas the inspectors are done with Glamour.
Hence, to add support for ProtoObject debugging you need: - to make interpretation implemented in Context compliant - to make EyeInspector compliant (for the inspector in the debugger) - to make GTInspector compliant.
I am not sure I understand what you mean by " interpretation implemented in Context compliantâ. Could you explain?
http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-May/164282.html
I already made GTInspector and GTDebugger work with ProtoObject once. I lost the changes in the meantime :), but I will redo them. The only thing I needed were these primitives. But, maybe I missed something.
Cheers, Doru
Cheers !
Clement
2016-01-04 16:42 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo:
object: anObject basicAt: index object: anObject basicAt: index put: value object: anObject eqeq: anOtherObject object: anObject instVarAt: anIndex object: anObject instVarAt: anIndex put: aValue object: anObject perform: selector withArguments: argArray inClass: lookupClass objectClass: anObject objectSize: anObject
I added an issue and the slice: https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides.
I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods?
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
-- www.tudorgirba.com www.feenk.com
"Things happen when they happen, not when you talk about them happening."
_,,,^..^,,,_ (phone)
Hi,
On Jan 4, 2016, at 7:26 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Doru,
On Jan 4, 2016, at 8:35 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Jan 4, 2016, at 6:30 PM, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
This is unrelated to Spur / SqueakV3 memory manager. The VM support has been there and stable for a long time now.
I tried to add those primitives in Pharo but the problem is that the debugger in Pharo uses EyeInspector whereas the inspectors are done with Glamour.
Hence, to add support for ProtoObject debugging you need: - to make interpretation implemented in Context compliant - to make EyeInspector compliant (for the inspector in the debugger) - to make GTInspector compliant.
I am not sure I understand what you mean by " interpretation implemented in Context compliantâ. Could you explain?
http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-May/164282.html
Thanks! Doru
I already made GTInspector and GTDebugger work with ProtoObject once. I lost the changes in the meantime :), but I will redo them. The only thing I needed were these primitives. But, maybe I missed something.
Cheers, Doru
Cheers !
Clement
2016-01-04 16:42 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo:
object: anObject basicAt: index object: anObject basicAt: index put: value object: anObject eqeq: anOtherObject object: anObject instVarAt: anIndex object: anObject instVarAt: anIndex put: aValue object: anObject perform: selector withArguments: argArray inClass: lookupClass objectClass: anObject objectSize: anObject
I added an issue and the slice: https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides.
I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods?
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
-- www.tudorgirba.com www.feenk.com
"Things happen when they happen, not when you talk about them happening."
_,,,^..^,,,_ (phone)
-- www.tudorgirba.com www.feenk.com "Every successful trip needs a suitable vehicle."
2016-01-04 17:35 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Jan 4, 2016, at 6:30 PM, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
This is unrelated to Spur / SqueakV3 memory manager. The VM support has been there and stable for a long time now.
I tried to add those primitives in Pharo but the problem is that the debugger in Pharo uses EyeInspector whereas the inspectors are done with Glamour.
Hence, to add support for ProtoObject debugging you need: - to make interpretation implemented in Context compliant - to make EyeInspector compliant (for the inspector in the debugger) - to make GTInspector compliant.
I am not sure I understand what you mean by " interpretation implemented in Context compliantâ. Could you explain?
The generic idea is that in the debugger part of the execution is done using an in-image interpreter instead of the VM. The in-image interpreter should use the mirror primitives to be able to interpret correctly the code. For example: Context>>pushReceiverVariable: offset self push: (self receiver instVarAt: offset + 1) should be rewritten: Context>>pushReceiverVariable: offset self push: (*self object:* self receiver instVarAt: offset + 1) Else operations such as "over" or "into" in the debugger would crash if the receiver is a protoobject as they would use this code which sends a message to a protoobject instead of using the mirror primitives.
I already made GTInspector and GTDebugger work with ProtoObject once. I lost the changes in the meantime :), but I will redo them. The only thing I needed were these primitives. But, maybe I missed something.
This is good news. I believe such inspectors are really important if one want to experiment with the kernel. The next steps would be to see if one can inspect an object which class directly inherit from nil and an object which has itself as a class (a prototype).
Cheers, Doru
Cheers !
Clement
2016-01-04 16:42 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo:
object: anObject basicAt: index object: anObject basicAt: index put: value object: anObject eqeq: anOtherObject object: anObject instVarAt: anIndex object: anObject instVarAt: anIndex put: aValue object: anObject perform: selector withArguments: argArray inClass: lookupClass objectClass: anObject objectSize: anObject
I added an issue and the slice:
https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
As I note in the issue, I think it is certainly interesting to have a
more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides.
I would like to use these primitives now to make the GT Inspector and
Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods?
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Problem solving efficiency grows with the abstractness level of problem
understanding."
-- www.tudorgirba.com www.feenk.com
"Things happen when they happen, not when you talk about them happening."
Hi,
On Jan 4, 2016, at 7:42 PM, Clément Bera <bera.clement@gmail.com> wrote:
2016-01-04 17:35 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Jan 4, 2016, at 6:30 PM, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
This is unrelated to Spur / SqueakV3 memory manager. The VM support has been there and stable for a long time now.
I tried to add those primitives in Pharo but the problem is that the debugger in Pharo uses EyeInspector whereas the inspectors are done with Glamour.
Hence, to add support for ProtoObject debugging you need: - to make interpretation implemented in Context compliant - to make EyeInspector compliant (for the inspector in the debugger) - to make GTInspector compliant.
I am not sure I understand what you mean by " interpretation implemented in Context compliantâ. Could you explain?
The generic idea is that in the debugger part of the execution is done using an in-image interpreter instead of the VM. The in-image interpreter should use the mirror primitives to be able to interpret correctly the code.
For example:
Context>>pushReceiverVariable: offset self push: (self receiver instVarAt: offset + 1)
should be rewritten:
Context>>pushReceiverVariable: offset self push: (self object: self receiver instVarAt: offset + 1)
Else operations such as "over" or "into" in the debugger would crash if the receiver is a protoobject as they would use this code which sends a message to a protoobject instead of using the mirror primitives.
Yep, I got this one. I was just not sure if there is maybe something else involved. I even did an analysis of what needs to be rewritten in this sense :) http://www.humane-assessment.com/blog/evaluating-the-reimplementation-of-key... Cheers, Doru
I already made GTInspector and GTDebugger work with ProtoObject once. I lost the changes in the meantime :), but I will redo them. The only thing I needed were these primitives. But, maybe I missed something.
This is good news. I believe such inspectors are really important if one want to experiment with the kernel. The next steps would be to see if one can inspect an object which class directly inherit from nil and an object which has itself as a class (a prototype).
Cheers, Doru
Cheers !
Clement
2016-01-04 16:42 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo:
object: anObject basicAt: index object: anObject basicAt: index put: value object: anObject eqeq: anOtherObject object: anObject instVarAt: anIndex object: anObject instVarAt: anIndex put: aValue object: anObject perform: selector withArguments: argArray inClass: lookupClass objectClass: anObject objectSize: anObject
I added an issue and the slice: https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides.
I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods?
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
-- www.tudorgirba.com www.feenk.com
"Things happen when they happen, not when you talk about them happening."
-- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."
Thank you Doru! When do you guess it is going to be integrated in the main codebase? Esteban A. Maringolo 2016-01-04 12:42 GMT-03:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo:
object: anObject basicAt: index object: anObject basicAt: index put: value object: anObject eqeq: anOtherObject object: anObject instVarAt: anIndex object: anObject instVarAt: anIndex put: aValue object: anObject perform: selector withArguments: argArray inClass: lookupClass objectClass: anObject objectSize: anObject
I added an issue and the slice: https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides.
I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods?
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
Hi Doru,
On Jan 4, 2016, at 7:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo:
object: anObject basicAt: index object: anObject basicAt: index put: value object: anObject eqeq: anOtherObject object: anObject instVarAt: anIndex object: anObject instVarAt: anIndex put: aValue object: anObject perform: selector withArguments: argArray inClass: lookupClass objectClass: anObject objectSize: anObject
I added an issue and the slice: https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides.
Note that a more powerful mirror implementation is still built upon these same primitives. Newspeak has a rich mirror implementation, but underneath it still uses these primitives to reach u side of objects without sending them messages.
I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods?
I can see no reason for delay. Remember that they should be used not only in low level inspectors but in Context's execution simulation machinery. Squeak can be used as a model, although in squeak there is still the ContextPart/MethodContext split.
Cheers, Doru
Happy new year!
www.tudorgirba.com www.feenk.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
_,,,^..^,,,_ (phone)
Hi, In summary, it seems we should integrate this one. I resolved the issue to "Resolved (Fix Review Needed)â, but it seems that the Monkey is still on holidays :). Does anyone know if there is a problem with it? Cheers, Doru
On Jan 4, 2016, at 5:42 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo:
object: anObject basicAt: index object: anObject basicAt: index put: value object: anObject eqeq: anOtherObject object: anObject instVarAt: anIndex object: anObject instVarAt: anIndex put: aValue object: anObject perform: selector withArguments: argArray inClass: lookupClass objectClass: anObject objectSize: anObject
I added an issue and the slice: https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides.
I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods?
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
-- www.tudorgirba.com www.feenk.com "We are all great at making mistakes."
All the Inria integration got a problem and this is restarting to work. So we will get there. Stef Le 5/1/16 20:38, Tudor Girba a écrit :
Hi,
In summary, it seems we should integrate this one.
I resolved the issue to "Resolved (Fix Review Needed)â, but it seems that the Monkey is still on holidays :). Does anyone know if there is a problem with it?
Cheers, Doru
On Jan 4, 2016, at 5:42 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo:
object: anObject basicAt: index object: anObject basicAt: index put: value object: anObject eqeq: anOtherObject object: anObject instVarAt: anIndex object: anObject instVarAt: anIndex put: aValue object: anObject perform: selector withArguments: argArray inClass: lookupClass objectClass: anObject objectSize: anObject
I added an issue and the slice: https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides.
I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods?
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
-- www.tudorgirba.com www.feenk.com
"We are all great at making mistakes."
Ok. No problem. Please let me know if I can help. Doru
On Jan 5, 2016, at 10:04 PM, stepharo <stepharo@free.fr> wrote:
All the Inria integration got a problem and this is restarting to work. So we will get there.
Stef
Le 5/1/16 20:38, Tudor Girba a écrit :
Hi,
In summary, it seems we should integrate this one.
I resolved the issue to "Resolved (Fix Review Needed)â, but it seems that the Monkey is still on holidays :). Does anyone know if there is a problem with it?
Cheers, Doru
On Jan 4, 2016, at 5:42 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
The VM (both Cog and Spur) supports basic manipulation of objects without relying on sending messages to those objects. These primitives are meant to be handled by methods in Context. Eliot provided a changeset with these methods, and they are not yet in Pharo:
object: anObject basicAt: index object: anObject basicAt: index put: value object: anObject eqeq: anOtherObject object: anObject instVarAt: anIndex object: anObject instVarAt: anIndex put: aValue object: anObject perform: selector withArguments: argArray inClass: lookupClass objectClass: anObject objectSize: anObject
I added an issue and the slice: https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
As I note in the issue, I think it is certainly interesting to have a more powerful mirrors mechanism, but until then we should still be able to use what the VM already provides.
I would like to use these primitives now to make the GT Inspector and Debugger be able to work with ProtoObject. I thought these methods were supposed to be in the Spur version of Pharo, but it seems they are not. So, I am wondering if maybe I am not missing something. Am I missing something or should we integrate these methods?
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
-- www.tudorgirba.com www.feenk.com
"We are all great at making mistakes."
-- www.tudorgirba.com www.feenk.com "When people care, great things can happen."
On 05 Jan 2016, at 21:04, stepharo <stepharo@free.fr> wrote:
All the Inria integration got a problem and this is restarting to work. So we will get there.
Something is still broken: https://ci.inria.fr/pharo/ all slaves are blocked with threads that are dead. Marcus
Le 6 janv. 2016 à 08:11, Marcus Denker a écrit :
On 05 Jan 2016, at 21:04, stepharo <stepharo@free.fr> wrote:
All the Inria integration got a problem and this is restarting to work. So we will get there.
Something is still broken:
all slaves are blocked with threads that are dead.
It looks like Jenkins is mess up with a job number. I need to find the job causing that and I think I could fix that
participants (7)
-
Christophe Demarey -
Clément Bera -
Eliot Miranda -
Esteban A. Maringolo -
Marcus Denker -
stepharo -
Tudor Girba