[00:12:40] *** alesj1 has joined #weld-dev
[00:13:55] *** alesj has quit IRC
[00:16:03] *** struberg has quit IRC
[00:24:29] *** mathieuancelin has quit IRC
[00:31:55] *** alesj1 has quit IRC
[00:58:11] *** cbrock has quit IRC
[01:15:55] *** kevinpollet has quit IRC
[01:30:43] *** rruss has quit IRC
[01:55:16] *** mbg has quit IRC
[01:57:42] *** aslak has quit IRC
[03:11:31] *** mbg has joined #weld-dev
[04:19:21] *** magesh has joined #weld-dev
[04:36:27] *** rruss has joined #weld-dev
[06:40:15] *** mbg has quit IRC
[06:40:46] *** mbg has joined #weld-dev
[07:07:43] *** oskutka has joined #weld-dev
[07:12:40] *** oskutka has quit IRC
[07:13:54] *** oskutka has joined #weld-dev
[07:20:55] *** alesj has joined #weld-dev
[08:08:10] *** mkouba has joined #weld-dev
[08:49:30] *** struberg has joined #weld-dev
[08:51:07] *** maschmid has joined #weld-dev
[08:51:22] *** emmanuel has joined #weld-dev
[08:51:23] *** emmanuel has quit IRC
[08:51:23] *** emmanuel has joined #weld-dev
[08:52:40] <struberg> anyone up and running atm?
[08:52:51] <stuartdouglas> sort of
[08:52:54] <struberg> have a question reg the spec and parameterized type handling in Beans
[08:53:00] <struberg> Bean as Bean<T>
[08:53:01] <stuartdouglas> for some definition of up and running :-)
[08:53:07] <struberg> heh ;)
[08:53:15] <struberg> I just had my first coffee (barely)
[08:53:44] <struberg> the spec states that
[08:53:45] <stuartdouglas> I did not really sleep last night for some reason, and I have had about 5 coffees and 500ml of red bull
[08:53:55] <struberg> If the managed bean class is a generic type, it must have scope @Dependent.
[08:54:00] <stuartdouglas> and I still feel tired
[08:54:10] <stuartdouglas> where at?
[08:54:20] <struberg> but Instance is not such a dependent bean, isn't?
[08:54:27] <struberg> 3.1
[08:54:33] <stuartdouglas> I don't think instance is a managed bean in this case
[08:54:50] <stuartdouglas> I think by managed bean it is referring to beans discovered via bean discovery
[08:54:56] <stuartdouglas> not any Bean
[08:54:58] <struberg> so you do the injection in a special way?
[08:55:19] <struberg> injection of Instance<T>
[08:55:32] <stuartdouglas> yea, there is special case code for resolving Instance<T>
[08:55:39] <struberg> oh kk
[08:55:44] <stuartdouglas> I think the spec is worried about class MyClass<T> {}
[08:55:57] <stuartdouglas> and then you inject it as MyClass<A> and MyClass<B>
[08:56:11] <stuartdouglas> it would not make sense for any scope other than @Dependent
[08:56:53] <stuartdouglas> because otherwise MyClass<A> and MyClass<B> would refer to the same underlying object, and cause ClassCastExceptions (probably)
[08:57:25] <stuartdouglas> The first sentence of 3.1 clarifies this "A managed bean is a bean that is implemented by a Java class"
[08:57:38] <stuartdouglas> so that restriction does not apply to Instance<>
[08:58:05] <struberg> yup because then we need 1 bean for discovery
[08:58:05] <struberg> and n bean instances for maintaining the map in the contexts
[08:58:05] <struberg> or even do beanManager.getReference(..
[08:58:05] <struberg> with the TypeLiteral as trick
[08:58:05] <struberg> not sure about that
[08:58:06] <struberg> you could have a @Inject Cache<User> userCache;
[08:58:06] <struberg> and @Inject Cache<Admin> adminCache;
[08:58:07] <struberg> both @SessionScoped
[08:58:07] <struberg> would make sense from a user pov
[08:58:19] <struberg> kk
[08:58:28] <struberg> and neither for Events then?
[08:58:40] <stuartdouglas> no, not for events either
[08:58:42] <struberg> same story over there...
[08:59:02] <stuartdouglas> personally I would not mind it if we allowed Cache<User>  and Cache<Admin>
[08:59:08] <stuartdouglas> but it would require additions to the spec
[08:59:11] *** mathieuancelin has joined #weld-dev
[08:59:26] <stuartdouglas> you would need to inspect all the injection points and look at all the different type parameters
[08:59:34] <stuartdouglas> and then register 1 bean per injection point type
[08:59:40] <stuartdouglas> which seems overly complex
[09:00:14] *** jharting has joined #weld-dev
[09:00:17] *** kevinpollet has joined #weld-dev
[09:01:20] <struberg> from a user pov it would be cool
[09:01:20] <struberg> but of course we still only have one single Cache<T> as bean
[09:01:21] <struberg> but we need n contextual instances
[09:01:21] <struberg> thus any legacy context would fail
[09:01:22] <struberg> stu, this already happens (injection point lookup)
[09:01:22] <struberg> at the time you inject the proxies
[09:01:23] <struberg> and the proxy knows exactly which parameterized type it would need
[09:01:23] <struberg> same with getReference
[09:01:24] <struberg> so this would not be the problem
[09:01:25] <struberg> only issue I see is that we would need to create parameterizedBeans from Bean<Cache<T>> on the fly
[09:01:30] <struberg> for storing the contextual instances in the contexts
[09:02:00] <struberg> guess I need to let this rest on me ;)
[09:02:12] <struberg> I'll think about it for a few days
[09:03:10] <stuartdouglas> struberg: I think there are other implications, I don't know how well creating beans on the fly would work
[09:03:24] <struberg> yup
[09:03:26] <stuartdouglas> and I am not sure what you mean when you say this already happens
[09:03:46] <struberg> in OWB we have an InstanceBean
[09:03:57] <struberg> which creates the Instance instances ;)
[09:04:03] <stuartdouglas> I think the only way you could make it work is like @New beans, where they are defined by the injection point
[09:04:08] <struberg> but it feels kind of hacky
[09:04:14] <stuartdouglas> yea
[09:04:19] <struberg> @New is broken too ;)
[09:04:23] <struberg> imo ^^
[09:04:25] *** ge0ffrey has joined #weld-dev
[09:04:26] <stuartdouglas> in OWB?
[09:04:34] <struberg> see the producer method discussion on the cdi dev list
[09:04:37] <struberg> nope
[09:04:40] <struberg> spec
[09:04:45] <struberg> not broken, but not that usable
[09:04:49] <struberg> its very limited atm
[09:05:04] <struberg> you can only use @New for Beans which are defined classes
[09:05:07] <stuartdouglas> I read that discussion, but I think that is beyond the scope of @New
[09:05:16] <struberg> oki that might also be
[09:05:28] <struberg> It was surely not intended
[09:05:28] <stuartdouglas> personally I think that we should not have made all classes beans
[09:05:35] <struberg> but thats what the users understand
[09:05:48] <struberg> "@New create a new instance from a Bean"
[09:05:55] <stuartdouglas> and if you want to inject something that does not have a scope annotation you have to use @New
[09:05:55] <struberg> but a producer method is also a bean
[09:06:15] <struberg> if it doesnt have a scope annotation, then it is @Dependent ;)
[09:06:59] <stuartdouglas> that is what I mean, instead of making everything a bean, if you want to use DI on something that is not a bean you have to use @New
[09:07:10] <stuartdouglas> but it is to late for that anyway :-(
[09:07:15] <struberg> kk :)
[09:07:19] <struberg> gn8 stu
[09:07:23] <struberg> and txs 4 the chat
[09:07:55] <stuartdouglas> It's actually not night over here, it's only 5pm
[09:08:08] <stuartdouglas> I'm just really tired :-)
[09:11:47] <struberg> had a cold too last week
[09:12:06] <struberg> one feels like wasted when not 100% healthy
[09:12:10] <alesj> btw: is @New supposed to work on interfaces?
[09:12:15] <stuartdouglas> no
[09:12:26] <alesj> uf ? bad
[09:12:31] <stuartdouglas> it would not make any sense
[09:12:40] <stuartdouglas> what did you expect it to do?
[09:12:44] <alesj> i would think CDI would be smart enough to know which bean needs to instantiate
[09:12:57] <alesj> @Inject @New Shape shape;
[09:13:16] <stuartdouglas> @New does not really work that way
[09:13:16] <alesj> where only Square implements Shape in my bean archive
[09:13:28] <alesj> hence I would expect to get new Sq instance
[09:13:34] <stuartdouglas> The main use for @New is actually to inject a bean that is not stored in a bean archive
[09:13:46] <stuartdouglas> actually no its not
[09:13:59] <stuartdouglas> never mind me, I'm just talking out my arse :-)
[09:14:03] <struberg> alesj that was my issue too
[09:14:17] <struberg> it is defined that way that it only makes sense to create new instances of classes
[09:14:18] <alesj> no, imo it's intended to get fresh un-managed bean instance
[09:14:20] <alesj> for some reason
[09:14:26] <struberg> no producer methods, no spezialized, alternative, etc
[09:14:28] <alesj> it's a corner case really
[09:14:45] <stuartdouglas> I have never used it
[09:14:52] <alesj> yeah, i was surprised on how it works
[09:15:04] <alesj> as I used it for my workshop ? for the first time as well
[09:15:19] <alesj> hence expecting @Inject @New Shape will work
[09:15:33] <alesj> but it simply complained it cannot instantiate interface ? doh!
[09:15:35] <stuartdouglas> It actually caused some big performance problems in weld at one point, cause we were registering an @New bean for every bean, rather than just the ones injected via @New
[09:15:44] <stuartdouglas> so we had twice as many beans as we needed
[09:15:55] <struberg> stu but you need to
[09:16:05] <struberg> because one can programmatically use getReference
[09:16:22] <struberg> and beanManager getBean(MyClass.class, NewLiteral)
[09:16:23] <stuartdouglas> nope "is enabled, in the sense of Section 5.1.2, ?Enabled and disabled beans?, if and only if some other enabled bean has an injection point with the qualifier @New(X.class) where X is the bean class."
[09:16:41] <stuartdouglas> so in that case the bean is disabled, and getReference is not supposed to work
[09:16:55] <struberg> but that is expected to work regarding the spec
[09:17:22] <struberg> thats written in the spec
[09:17:27] <stuartdouglas> no, unless the user injects it the bean is disabled
[09:17:40] <struberg> but thats not whats in the spec
[09:17:43] <stuartdouglas> and you can't use getReference to get a disabled bean
[09:17:56] <stuartdouglas> which spec version?
[09:18:07] <struberg> For each managed bean, and for each session bean, a second bean exists which ?.
[09:18:09] <struberg> 1.0
[09:18:14] <struberg> section 3.12
[09:18:21] <stuartdouglas> struberg: yes, but 99% of the time that bean is disabled
[09:18:24] <struberg> you can really manually lookup new beans
[09:18:30] <struberg> yes,
[09:18:33] <stuartdouglas> so has no effect on the deployement
[09:18:37] <stuartdouglas> and can't be looked up
[09:18:38] <struberg> but that doesnt mean that it must not work ^^
[09:18:45] <stuartdouglas> yes it does
[09:18:59] <struberg> you could lazily create that bean
[09:19:02] <stuartdouglas> "enabled IF AND ONLY IF"
[09:19:24] <struberg> ahhh oki, I c
[09:19:28] <stuartdouglas> no injection point, the bean is disabled, you can't use getReference
[09:19:46] <struberg> I c
[09:19:51] <struberg> thanks for the pointer
[09:19:54] <struberg> overread that
[09:20:11] <stuartdouglas> so are you registering @New beans for every bean in OWB?
[09:21:10] <struberg> yup atm
[09:21:13] <stuartdouglas> if so you might get a decent memory usage / startup time increase if you stop
[09:21:22] <stuartdouglas> decrease not increase
[09:21:23] <struberg> heh yes
[09:21:54] <alesj> so, should CDI 1.1 fix how @New behaves on interfaces?
[09:21:55] <alesj> :-)
[09:22:41] <stuartdouglas> I don't think so
[09:22:48] <stuartdouglas> it would be really fragile
[09:22:58] <alesj> why not? that's the only natural behavior I would expect
[09:23:09] <stuartdouglas> it would only work if you had exactly one bean that implements the interface in your app
[09:23:14] <alesj> imo, as I should never know the actual impl
[09:23:25] <stuartdouglas> and if you add an additional bean you can't discriminate via qualifiers
[09:23:34] <alesj> why not?
[09:23:46] <stuartdouglas> actually, You may be able to use @New(MyImpl.class) as the qualifier
[09:23:47] <alesj> @Inject @Blue @New
[09:24:05] <alesj> see which exact bean has @Blue
[09:24:07] <stuartdouglas> alesj: the spec says @New beans can't have qualifiers (except for @New)
[09:24:10] <alesj> and instantiate new instance
[09:24:46] <alesj> that's stupid
[09:25:09] <alesj> i don't care about which bean impls my injection point
[09:25:15] <alesj> i just need to get a new instance of it
[09:25:19] <stuartdouglas> like I said, I've never used them, don't know of anyone who has :-)
[09:25:28] <alesj> my workshop :-)
[09:25:59] <alesj> i mummbled a bit, distraced users with some other stuff and carried on :-)
[09:26:03] <alesj> at @New usage
[09:26:33] <stuartdouglas> I just don't talk about it
[09:26:41] <alesj> i can see yes :-)
[09:26:50] <alesj> aha, another bug i found
[09:26:54] <alesj> if you have some idea
[09:27:10] <alesj> Msg<T>
[09:27:27] <alesj> then I had x(@Observes Msg<Number> x)
[09:27:31] <alesj> working OK
[09:27:33] <alesj> btu
[09:27:34] <alesj> but
[09:27:51] <alesj> foo(@Observes Msg<byte[]> bytes)
[09:27:54] <alesj> did not work
[09:28:06] <alesj> Event<Msg<byte[]>> event
[09:28:21] <alesj> event.fire(new Msg<byte[]>(bytes))
[09:28:27] <stuartdouglas> hmm
[09:28:32] <alesj> did not get picked up by the matching observer
[09:28:45] <alesj> where all other did. String, Number, Date, ...
[09:28:52] <alesj> see my workshop example
[09:28:54] <stuartdouglas> what about other array types?
[09:28:59] <alesj> https://github.com/alesj/cdi-arq-workshop
[09:29:09] <alesj> haven't tried other array examples
[09:29:38] <alesj> https://github.com/alesj/cdi-arq-workshop/blob/master/cdi/src/test/java/org/jboss/test/workshop/cdi/observes/test/ObservesTestCase.java
[09:29:41] <stuartdouglas> It is probably some bug with array type resolution, which seems kinda
[09:29:43] <stuartdouglas> odd
[09:29:53] <stuartdouglas> because there are heaps of tests for that sort of thing
[09:30:03] <alesj> yeah, and class is a class
[09:30:13] <alesj> imo, it shouldn't matter if it's an array
[09:30:17] <stuartdouglas> no, array classes are special
[09:30:36] <alesj> why? i mean int this case ...
[09:30:52] <alesj> do we threat them diff?
[09:30:54] <stuartdouglas> the JVM treats them different, there is probably just some bug in the result ion code
[09:31:02] <stuartdouglas> give me a sec while I do up a test case
[09:31:14] <alesj> you can run my workshop example
[09:31:18] <alesj> it's embedded Weld
[09:32:00] <alesj> btw: stuartdouglas: did you already merge mathieuancelin' osgi stuff into master?
[09:32:07] <stuartdouglas> alesj: no
[09:32:11] <stuartdouglas> it needs an API change
[09:32:17] <stuartdouglas> it won't go into 1.1.3.GA
[09:32:29] <alesj> ah, ok
[09:33:16] <alesj> brb
[09:35:42] <mathieuancelin> stuartdouglas: I think Pete talk about the 1.2 version
[09:35:55] <stuartdouglas> mathieuancelin: yes
[09:35:57] <stuartdouglas> or 2.x
[09:36:02] <stuartdouglas> whatever we decide to do
[09:36:07] <mathieuancelin> yep
[09:36:19] <stuartdouglas> but api changes mean that weld is no longer a drop in replacement in app servers
[09:36:43] <mathieuancelin> yep that's the probleme
[09:37:01] <mathieuancelin> I tried not to change the API for a long time
[09:37:11] <mathieuancelin> but it was not convenient at all
[09:37:21] <mathieuancelin> and error prone
[09:41:51] *** rruss has quit IRC
[09:45:57] <stuartdouglas> alesj: according to the spec it should not work at all
[09:46:09] <stuartdouglas> CDI 10.1 An event object is an instance of a concrete Java class with no type variables.
[09:49:07] <stuartdouglas> struberg: Do you know of the reason for the 'no type variables' restriction for events?
[09:49:33] <stuartdouglas> it seems silly considering the container fires events with type variables at startup
[09:52:51] <stuartdouglas> CDI-169
[09:52:52] <jbossbot> jira [CDI-169] Remove the 'No type variable in event objects' restriction [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/CDI-169
[09:54:17] <alesj> stuartdouglas: hmmm, it could work ? as the type variable behavior looks like it's left to the impl
[09:59:17] <stuartdouglas> no, the spec forbids it, the TCK just does not check it
[09:59:27] <stuartdouglas> technically its a bug in weld
[10:01:41] *** aslak has joined #weld-dev
[10:02:08] <alesj> bug since it works :-)
[10:56:24] *** emmanuel has quit IRC
[10:59:40] *** magesh has quit IRC
[10:59:58] *** magesh has joined #weld-dev
[11:32:06] <mkouba> stuartdouglas: alesj: just commented CDI-169... just my humble opinion :-)
[11:32:08] <jbossbot> jira [CDI-169] Remove the 'No type variable in event objects' restriction [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/CDI-169
[11:38:10] *** magesh1 has joined #weld-dev
[11:38:22] *** magesh1 has quit IRC
[11:39:36] *** magesh has quit IRC
[11:51:04] <stuartdouglas> mkouba: I responded
[11:51:15] <stuartdouglas> even if that was the intent (and I think it probably was)
[11:51:21] <stuartdouglas> The language is poor
[11:59:31] <mkouba> stuartdouglas: I agree it should be clarified... but don't know anything about intent... I think Pete will tell us
[12:02:40] *** epbernard has joined #weld-dev
[12:02:40] *** epbernard is now known as emmanuel
[12:40:33] *** magesh has joined #weld-dev
[12:41:25] *** magesh has quit IRC
[12:41:25] *** magesh has joined #weld-dev
[12:42:31] *** magesh1 has joined #weld-dev
[12:44:24] *** magesh1 has quit IRC
[12:45:10] *** magesh has quit IRC
[12:45:26] *** magesh has joined #weld-dev
[12:54:30] *** kevinpollet has quit IRC
[12:55:32] *** magesh has quit IRC
[13:02:06] *** alesj has quit IRC
[13:04:19] *** magesh has joined #weld-dev
[13:14:22] *** alesj has joined #weld-dev
[13:19:01] *** kevinpollet has joined #weld-dev
[13:32:13] *** pmuir has joined #weld-dev
[13:32:13] *** pmuir has quit IRC
[13:32:13] *** pmuir has joined #weld-dev
[13:46:22] <struberg> stu still around?
[13:46:29] <stuartdouglas> yes
[13:46:36] <struberg> for New beans
[13:46:44] <struberg> do you not create them at all
[13:46:48] <struberg> or only have them disabled?
[13:47:00] <struberg> so do they get returned via BeanManager#getBeans
[13:47:10] <struberg> and only dropped out by BM#resolve later?
[13:47:19] <struberg> or dont you create it at all?
[13:47:37] <stuartdouglas> struberg: We only create them if they are enabled
[13:47:40] <struberg> see Arnes last comment in https://issues.apache.org/jira/browse/OWB-619
[13:49:18] <struberg> ah oki there is actually no difference I guess
[13:49:24] <stuartdouglas> hmm, if thats the case we should change that in the next edition of the spec, it just seems silly to have to create thousands of disabled beans
[13:50:41] <struberg> also Bean<T> nor Contextual<T> have a isEnabled
[13:50:55] <struberg> so I guess what is meant is that the beans dont exist at all, pmuir can you please clarify?
[13:53:11] <struberg> guess its a bit confugins
[13:53:14] <struberg> confusing
[13:53:21] <struberg> but acually 11.1 states
[13:53:23] <struberg> > An instance of Bean exists for every enabled bean.
[13:53:41] <struberg> so in reverse for disabled beans we can assume that it does not exist
[13:53:46] <struberg> (Bean instance)
[13:53:53] <struberg> although this is not explicitely stated
[13:54:09] <struberg> (trinary logic as always)
[13:54:19] <struberg> too sad that only computer science is binary
[13:54:34] <struberg> the opposite of true might be either no or 'dont know' :)
[14:14:40] *** emmanuel has quit IRC
[14:14:48] *** epbernard has joined #weld-dev
[14:14:48] *** epbernard is now known as emmanuel
[14:23:58] <pmuir> stuartdouglas: sorry
[14:24:31] <pmuir> what are you talking about exactly?
[14:24:35] <pmuir> what @New beans need to exist?
[14:25:29] <stuartdouglas> yea
[14:26:02] <stuartdouglas> the way the spec is phased where there is one @New bean for every managed bean, but 99% are disabled
[14:26:09] <alesj> pmuir: @New is broken anyway ? as per spec ;-)
[14:26:19] <pmuir> just the ones for which their are injection points
[14:27:20] <pmuir> as struberg said, you only need a Bean object for every enabled bean
[14:27:29] <pmuir> and the only enabled @New beans are those with an IP
[14:27:43] <pmuir> it's phrased like that for a reason
[14:27:50] <pmuir> to prevent insane numbers of Beans being created
[14:27:57] <pmuir> I implemented weld like that
[14:28:02] <pmuir> alesj:?
[14:28:14] *** maschmid has left #weld-dev
[14:28:24] *** maschmid has quit IRC
[14:28:40] *** maschmid has joined #weld-dev
[14:28:41] <alesj> pmuir: imo, natural behavior, as I would expect it ? and struberg as well ? is to be able to do @Inject @New Shape shape;
[14:28:53] <alesj> where Square implements Shape
[14:29:03] <alesj> would result in new Square instance
[14:30:01] <pmuir> how does CDI know this? because Shape is an interface or sth?
[14:31:43] <alesj> yes, Shape is an interface
[14:32:32] <pmuir> hmm
[14:32:38] <pmuir> i'm not sure how we can fix this
[14:32:44] <pmuir> @New is odd
[14:32:54] <pmuir> i'm not sure it was a very good soln to the problem
[14:33:13] <alesj> since CDI is all about types and its impls
[14:33:28] <alesj> i would expect CDI to know which Shape impl it needs to instantiate
[14:33:48] <alesj> if there are more, it should be qualifiers that limit it
[14:33:58] <alesj> e.g. @Inject @Blue @New Shape shape;
[14:35:11] <pmuir> yeah
[14:35:24] <pmuir> @New is trying to do something specific
[14:35:28] <pmuir> not that ;-)
[14:35:37] <pmuir> and i think in hindsight it's just confusing
[14:35:45] <struberg> but as I said yesterday
[14:35:55] <struberg> most people think its useful for much more ;)
[14:35:58] <pmuir> yep
[14:36:31] <struberg> btw, about enabled and disabled beans
[14:36:32] <struberg> https://issues.apache.org/jira/browse/OWB-619
[14:36:38] <struberg> anyone like to join in ?
[14:36:46] <struberg> might be a spec clarification needed ...
[14:37:02] <pmuir> i think it's probably better to concentrate on improving instance to cope with these cases
[14:38:14] <pmuir> not really, it sounds like you have the right idea
[14:38:24] <pmuir> the spec is clear today aiui but the intent isn't
[14:49:32] *** rruss has joined #weld-dev
[15:06:37] *** emmanuel has quit IRC
[15:06:41] *** epbernard has joined #weld-dev
[15:06:41] *** epbernard is now known as emmanuel
[15:20:36] *** epbernard has joined #weld-dev
[15:21:21] *** epbernard has quit IRC
[15:21:21] *** epbernard has joined #weld-dev
[15:21:43] *** alesj has quit IRC
[15:22:29] *** emmanuel has quit IRC
[15:27:22] *** mkouba has quit IRC
[15:47:12] *** mbg has quit IRC
[16:04:53] *** epbernard has quit IRC
[16:11:13] *** emmanuel has joined #weld-dev
[16:21:42] *** jharting has quit IRC
[16:42:47] *** oskutka has quit IRC
[17:00:03] *** mathieuancelin has quit IRC
[17:02:13] *** mathieuancelin has joined #weld-dev
[17:11:05] *** mbg has joined #weld-dev
[17:11:13] *** mbg has quit IRC
[17:11:13] *** mbg has joined #weld-dev
[17:37:18] *** kevinpollet has quit IRC
[17:47:31] *** cbrock has joined #weld-dev
[17:48:36] *** kevinpollet has joined #weld-dev
[17:49:57] *** mathieuancelin has left #weld-dev
[17:52:58] *** kevinpollet has quit IRC
[17:55:12] *** mkouba has joined #weld-dev
[18:05:40] *** maschmid has quit IRC
[18:29:06] *** mbg has quit IRC
[18:30:02] *** mbg has joined #weld-dev
[18:30:04] *** mbg has joined #weld-dev
[18:32:24] *** ge0ffrey has quit IRC
[18:33:21] *** mbg has left #weld-dev
[18:33:31] *** mbg has joined #weld-dev
[18:35:46] *** mbg has quit IRC
[18:36:01] *** mbg has joined #weld-dev
[18:36:05] *** mbg has joined #weld-dev
[18:42:18] *** oskutka1 has joined #weld-dev
[18:47:00] *** mathieuancelin has joined #weld-dev
[18:50:33] *** rruss has quit IRC
[19:17:12] *** kevinpollet has joined #weld-dev
[19:20:48] *** mkouba has quit IRC
[19:22:00] *** aslak has quit IRC
[19:22:19] *** aslak has joined #weld-dev
[19:23:00] *** rruss has joined #weld-dev
[20:16:12] *** kevinpollet has quit IRC
[20:48:40] *** emmanuel has quit IRC
[21:06:21] *** alesj has joined #weld-dev
[22:01:07] *** alesj has quit IRC
[23:09:52] *** mathieuancelin has quit IRC
[23:32:09] *** rmartinelli has quit IRC





top