[00:15:53] *** alesj has quit IRC
[00:35:43] *** johnament has joined #weld-dev
[00:38:26] *** aslak has quit IRC
[00:40:50] *** johnament has quit IRC
[00:51:39] *** johnament has joined #weld-dev
[01:08:07] *** johnament has quit IRC
[02:24:43] *** johnament has joined #weld-dev
[02:30:11] *** sbryzak has quit IRC
[02:46:40] *** sbryzak has joined #weld-dev
[02:46:40] *** sbryzak has joined #weld-dev
[03:02:13] *** magesh has joined #weld-dev
[03:02:15] *** magesh has quit IRC
[03:02:15] *** magesh has joined #weld-dev
[03:02:27] *** magesh has quit IRC
[03:24:44] *** echelog-2 has joined #weld-dev
[05:35:56] *** johnament has quit IRC
[08:12:56] *** jharting has joined #weld-dev
[08:35:44] *** oskutka has joined #weld-dev
[08:37:33] *** alesj has joined #weld-dev
[08:54:31] *** emmanuel has joined #weld-dev
[08:58:41] *** maschmid has joined #weld-dev
[09:29:57] *** kevinpollet has joined #weld-dev
[09:43:55] *** mathieuancelin has joined #weld-dev
[10:21:11] *** oskutka has quit IRC
[10:22:27] *** oskutka has joined #weld-dev
[10:34:22] *** maschmid has quit IRC
[10:35:55] *** oskutka has quit IRC
[10:36:53] *** maschmid has joined #weld-dev
[10:37:09] *** oskutka has joined #weld-dev
[11:00:17] <stuartdouglas> alesj: I just noticed AnnotationLiteral in the CDI-API does not cache it's hashCode
[11:00:38] <stuartdouglas> but instead calculates it using reflection each time
[11:01:05] <stuartdouglas> Is the CDI jira the right place to create a JIRA for this?
[11:03:04] <alesj> stuartdouglas: i would say so, yes
[11:03:50] *** emmanuel has quit IRC
[11:10:46] *** maschmid has quit IRC
[11:19:09] *** alesj has quit IRC
[11:19:09] *** alesj1 has joined #weld-dev
[11:32:21] *** alesj1 has quit IRC
[11:38:57] *** mathieuancelin has quit IRC
[11:40:03] *** mathieuancelin has joined #weld-dev
[11:44:48] *** alesj has joined #weld-dev
[11:57:56] *** epbernard has joined #weld-dev
[11:57:56] *** epbernard is now known as emmanuel
[12:08:06] *** mathieuancelin_ has joined #weld-dev
[12:08:06] *** mathieuancelin has quit IRC
[12:08:06] *** mathieuancelin_ is now known as mathieuancelin
[12:15:34] *** maschmid has joined #weld-dev
[12:17:47] *** kevinpollet has quit IRC
[12:18:54] *** aslak has joined #weld-dev
[12:18:55] *** aslak has joined #weld-dev
[12:19:47] *** mathieuancelin has quit IRC
[13:14:17] *** mathieuancelin has joined #weld-dev
[13:14:46] *** kevinpollet has joined #weld-dev
[13:41:02] *** pmuir has joined #weld-dev
[13:41:03] *** pmuir has quit IRC
[13:41:03] *** pmuir has joined #weld-dev
[13:58:56] <pmuir> mathieuancelin: alesj: ping are you still ok to talk about OSGi and Weld in 10 mins?
[13:59:35] <mathieuancelin> pmuir: yep it's ok for me
[14:03:40] *** arcane86 has joined #weld-dev
[14:04:24] *** emmanuel has quit IRC
[14:04:51] <alesj> pmuir: ping
[14:05:11] <pmuir> hi alesj
[14:06:00] <alesj> hey
[14:06:05] <alesj> do we have number details?
[14:06:39] <alesj> pmuir: ^
[14:06:50] *** arcane86 has left #weld-dev
[14:06:51] <pmuir> what are "number details"?
[14:07:25] <alesj> confcall number
[14:07:36] <alesj> ah, or are we gonna chat here about that?
[14:07:42] *** matthieuclochard has joined #weld-dev
[14:07:47] <alesj> pmuir: /6
[14:07:49] <alesj> ^
[14:08:01] <pmuir> ah, I think the plan wsa to talk here
[14:08:07] <alesj> ok, fine by me
[14:09:46] <mathieuancelin> matthieuclochard is here too
[14:09:55] <mathieuancelin> he worked a lot on weld-osgi lately
[14:10:01] <pmuir> great
[14:10:37] <pmuir> so i suggested this meeting just to bring everyone up to speed with current status, and also to try to define the schedule for getting this work finished up...
[14:10:48] <pmuir> and to discuss any tech issues we need to
[14:10:49] <mathieuancelin> ok
[14:10:53] <mathieuancelin> so
[14:11:39] <mathieuancelin> the project is still hosted here https://github.com/mathieuancelin/weld-osgi
[14:11:47] <mathieuancelin> with some issues
[14:11:58] <mathieuancelin> https://github.com/mathieuancelin/weld-osgi/issues?milestone=
[14:12:08] <alesj> what other issues apart Singleton do we have?
[14:12:17] <mathieuancelin> but the major features are working right now
[14:12:43] <mathieuancelin> I don't think there is other issues
[14:12:47] <mathieuancelin> on the weld side
[14:13:06] <mathieuancelin> I posted an issue on jboss interceptor a while ago
[14:13:24] <mathieuancelin> but I use a trick to make it work in osgi
[14:13:29] <mathieuancelin> so it's not that important
[14:13:43] <alesj> how did you tackle around SingletonProvider?
[14:13:51] <mathieuancelin> ok
[14:13:57] <mathieuancelin> actually
[14:14:42] <mathieuancelin> I was inspired by the last talk about it
[14:14:47] <mathieuancelin> (maybe on the forum)
[14:15:03] <mathieuancelin> and I change the Singleton API
[14:15:13] <mathieuancelin> to pass some kind of contextual ID
[14:15:38] <mathieuancelin> https://github.com/mathieuancelin/api/blob/master/weld-spi/src/main/java/org/jboss/weld/bootstrap/api/Singleton.java
[14:15:45] <mathieuancelin> I'm not sure it's a good move
[14:15:52] <mathieuancelin> since it might break some code
[14:16:02] <mathieuancelin> in existing project
[14:16:29] <mathieuancelin> and with that new API
[14:16:59] <mathieuancelin> I changed Weld code to create container with an ID
[14:17:34] <mathieuancelin> https://github.com/mathieuancelin/core/commit/216b4b0a7af97f521dbf5de487ddb8cb31b71ea6
[14:17:36] <jbossbot> git [core] 216b4b0.. Mathieu ANCELIN Use the new Singleton API and use contextual ID for internal container instances
[14:18:44] <mathieuancelin> The idea behind this commit is to hold the container ID in beans, bean manager, etc ...
[14:19:06] <mathieuancelin> and use it to target the right container (or any object provided by Singleton)
[14:19:11] <alesj> and i guess you then use a lot of ThreadLocal to pass this around?
[14:19:18] <mathieuancelin> not one
[14:19:19] <mathieuancelin> :)
[14:19:41] 
[14:19:42] 
[14:19:42] 
[14:19:42] 
[14:19:58] <alesj> this looks like setting some temp instance
[14:20:27] <mathieuancelin> oopps
[14:20:32] <mathieuancelin> bad link
[14:20:47] <mathieuancelin> these were useless
[14:21:00] <mathieuancelin> I removed them in the following commits
[14:21:14] <alesj> :)
[14:21:35] <mathieuancelin> with this code
[14:21:53] <mathieuancelin> each bean (or internal Weld object) hold the id of their container
[14:22:06] <mathieuancelin> and use it to access the right weld container
[14:22:30] <mathieuancelin> of course, these changes doesn't affect the existing singleton providers
[14:22:43] <mathieuancelin> (except on the method signature part)
[14:23:06] <mathieuancelin> so it work the same with existing code
[14:23:09] <alesj> https://github.com/mathieuancelin/api/blob/master/weld-spi/src/main/java/org/jboss/weld/bootstrap/api/Singleton.java
[14:23:15] <alesj> this doesn't have diff signature
[14:23:20] <alesj> or, at least i don't see it
[14:24:25] *** oskutka1 has joined #weld-dev
[14:24:27] <matthieuclochard> wrong branch
[14:24:38] <mathieuancelin> erf bad branch
[14:24:42] *** oskutka has quit IRC
[14:24:42] <matthieuclochard> https://github.com/mathieuancelin/api/blob/singleton-id/weld-spi/src/main/java/org/jboss/weld/bootstrap/api/Singleton.java
[14:24:48] <pmuir> sorry on phone
[14:25:29] <mathieuancelin> and I introduce a new singleton provider that leverage the container id
[14:25:31] <mathieuancelin> https://github.com/mathieuancelin/api/blob/singleton-id/weld-spi/src/main/java/org/jboss/weld/bootstrap/api/helpers/RegistrySingletonProvider.java
[14:27:15] <alesj> we could probably make plain Object as key
[14:27:29] <alesj> where then TCCLSP could use TCCL as key
[14:27:43] <mathieuancelin> yep why not
[14:27:52] <alesj> this does break SPI significantly ...
[14:28:00] <mathieuancelin> yes
[14:28:05] <mathieuancelin> that the main issue
[14:28:25] <mathieuancelin> I try to use ThreadLocal to not brake the api
[14:28:32] <mathieuancelin> but I'm not big fan
[14:28:42] <pmuir> this seems like a good approach to me (ignoring the actual mechanics of releasing this ;-)
[14:28:53] <mathieuancelin> :)
[14:28:54] <pmuir> alesj: do you think we could include this in 1.2?
[14:29:37] <alesj> for us it's np
[14:29:47] <alesj> dunno how happy GF guys will be
[14:29:57] <mathieuancelin> we started some integration within weld project
[14:29:58] <mathieuancelin> https://github.com/mathieuancelin/core/tree/master/environments/osgi
[14:31:00] *** epbernard has joined #weld-dev
[14:31:00] *** epbernard is now known as emmanuel
[14:31:13] <mathieuancelin> it's organized like the weld-se project
[14:31:59] <mathieuancelin> it lacks documentation and samples modules
[14:32:09] <mathieuancelin> but matthieuclochard is on it
[14:33:17] <alesj> hmmm, pmuir do we actually use SP with any integration code
[14:33:24] <alesj> apart from setting the right one
[14:33:35] <alesj> SP = SingletonProvider
[14:33:43] <pmuir> i think it's just setting it up for the integration code
[14:33:46] <alesj> or, does GF do anything explicit with it
[14:33:48] <pmuir> usage is mainly internal
[14:33:55] <pmuir> we can email siva and ask him
[14:34:00] <alesj> yeah, thought so
[14:34:06] <pmuir> my feeling is that it will be ok if we give them warning
[14:34:07] <mathieuancelin> I think GF is using it's own SP
[14:34:31] <mathieuancelin> they had some kind of issues with TCCL and ear archives
[14:34:46] <pmuir> mathieuancelin: ok
[14:34:56] <alesj> but shouldn't this solve all problems
[14:35:02] <mathieuancelin> but maybe it's no more the case
[14:35:03] <alesj> e.g. no need for TCCL SP anymore
[14:35:13] <mathieuancelin> yep
[14:35:22] <mathieuancelin> we can use application name instead
[14:35:30] <mathieuancelin> or something like that
[14:36:31] <alesj> what do you use now?
[14:36:52] <alesj> and, how much code needed to be changed in order to support this? (i can look at the commit later)
[14:37:05] <alesj> e.g. where does this id "live" now?
[14:37:36] <mathieuancelin> right now
[14:37:42] <mathieuancelin> nothing change
[14:38:00] <mathieuancelin> except if you use the RegistrySingletonProvider
[14:38:05] <mathieuancelin> in weld-osgi
[14:38:07] <pmuir> btw https://gist.github.com/1162274
[14:38:20] <mathieuancelin> we use the bundle symbolic name + bundle id
[14:38:27] <mathieuancelin> as the singleton ID
[14:39:41] <mathieuancelin> and then
[14:39:44] <mathieuancelin> we do
[14:39:45] <mathieuancelin> bootstrap.startContainer(id, new OSGiEnvironment(), deployment);
[14:39:57] <mathieuancelin> to start the container with the good id
[14:40:01] <mathieuancelin> if you use
[14:40:05] <mathieuancelin> bootstrap.startContainer(new OSGiEnvironment(), deployment);
[14:40:11] <mathieuancelin> a default id is used
[14:40:28] <mathieuancelin> it's this part that need to be changed in GF
[14:40:42] <mathieuancelin> to leverage the ID mechanism
[14:41:09] <alesj> and how does this id then propagate through beans?
[14:41:17] <alesj> it needs to be kept somewhere, right?
[14:41:33] <alesj> i mean, in some Context
[14:41:48] <mathieuancelin> yep
[14:42:01] <alesj> to be used when you need to lookup SP
[14:42:11] <alesj> in order to lookup other beans from this same container
[14:42:12] <mathieuancelin> it's stored in every object that need to call Container.instance
[14:42:28] <mathieuancelin> i.e BeanManagerImp
[14:42:30] <mathieuancelin> etc ...
[14:42:57] <alesj> is there a single place where we could keep this
[14:43:00] <alesj> e.g. some abstract class
[14:43:06] <alesj> or do we go case-by-case
[14:43:06] <mathieuancelin> hum
[14:43:25] <mathieuancelin> it's more case-by-case right know
[14:43:33] <alesj> case-by-case == easy to miss some use case
[14:43:45] <alesj> not very likely ? but ?
[14:44:27] <mathieuancelin> yes I know
[14:44:48] <alesj> did you run this changes against some AS?
[14:44:52] <alesj> e.g. JBossAS7
[14:45:02] <alesj> with RegistrySP
[14:45:06] <mathieuancelin> I don't know if it's possible to use some kind of abstract classes
[14:45:16] <mathieuancelin> it's used il a lot of objects
[14:45:19] <mathieuancelin> hum
[14:45:26] <mathieuancelin> not at all
[14:46:02] <mathieuancelin> but to do that, we need to change the integration part (with AS7)
[14:46:29] <mathieuancelin> to use the RegistrySP (ie. start weld container with a unique ID)
[14:46:56] <alesj> the bootstrap::startC stuff?
[14:47:24] <alesj> i guess that shouldn't be too difficult
[14:47:37] <alesj> new AS7 branch with your Weld build, voila :-)
[14:48:22] <mathieuancelin> yep
[14:49:04] <alesj> i need to switch Weld to use AS7 anyway asap, with stuartdouglas' help
[14:49:12] <mathieuancelin> a WeldContainer is created for every deployed app with beans.xml right ?
[14:49:12] <alesj> perhaps wait till then
[14:49:42] <alesj> pmuir: ^
[14:50:03] <alesj> i know there is a Bootstrap per app
[14:50:18] <alesj> which then has Archive per beans.xml jar
[14:50:46] <mathieuancelin> ok
[14:50:48] <pmuir> alesj: you know this better than me...
[14:50:48] <alesj> WeldContainer is only in SE
[14:50:57] <pmuir> WeldContainer isn't used in JBoss AS 7
[14:51:24] <mathieuancelin> https://github.com/mathieuancelin/jboss-as/blob/master/weld/src/main/java/org/jboss/as/weld/WeldContainer.java
[14:51:26] <mathieuancelin> ?
[14:51:43] <alesj> ah, AS7
[14:51:45] <alesj> :-0
[14:51:49] <alesj> i did this for AS6
[14:51:50] <alesj> :-)
[14:52:00] <alesj> but let me check
[14:52:21] <mathieuancelin> it's not the AS7 repo ?
[14:52:49] <alesj> jboss-as
[14:52:55] <alesj> != weld
[14:53:19] <alesj> ok, WeldContainer in AS7 == Bootstrap
[14:53:28] <alesj> so yes, 1 WC per app
[14:53:47] *** oskutka1 has quit IRC
[14:53:56] <mathieuancelin> ok
[14:54:26] <mathieuancelin> is there something nice in WeldDeployment to extract an id ?
[14:54:45] <mathieuancelin> well I guess we can generate one randomly
[14:55:27] <alesj> or you can pass in the id from DeploymentUnit
[14:55:32] <alesj> the name there should be unique
[14:55:42] <mathieuancelin> ok
[14:55:49] <alesj> and more informative
[14:56:03] <mathieuancelin> do you know where the usage off TCCLSP is set ?
[14:56:43] <alesj> let me check ...
[14:56:55] <alesj> ModuleGroupSingletonProvider
[14:57:07] <alesj> hmmm, this looks suspicious
[14:57:15] <mathieuancelin> :)
[14:57:16] <alesj> perhaps TCCL is also not used
[14:57:20] <alesj> 1sec
[14:57:39] <mathieuancelin> maybe weld/src/main/java/org/jboss/as/weld/services/TCCLSingletonService.java ?
[14:57:39] <alesj> public class ModuleGroupSingletonProvider extends SingletonProvider {
[14:58:07] <alesj> it looks like public class ModuleGroupSingletonProvider extends SingletonProvider {
[14:58:10] <alesj> is the SP in AS7
[14:58:27] <mathieuancelin> SingletonProvider.initialize(new ModuleGroupSingletonProvider());
[15:00:23] <alesj> yup
[15:01:09] <alesj> TCCLSingletonService gets only registered once for the whole AS
[15:01:58] <mathieuancelin> ok
[15:02:06] <pmuir> can we just switch tack briefly, and get a task list finalised to get this included into Weld
[15:02:07] <pmuir> https://gist.github.com/1162274
[15:02:13] <pmuir> is my current list
[15:02:20] <pmuir> do we have anything else that neeeds to go on?
[15:02:26] <mathieuancelin> do U know how to get the deployment unit info from the WeldContainer class ?
[15:03:51] <alesj> WC gets created in WeldDeploymentProcessor
[15:03:57] <alesj> which is a deployer/processor
[15:04:06] <alesj> hence it has DU knowledge
[15:04:23] <alesj> you can just get the name from DU, and pass it into WC
[15:06:11] <mathieuancelin> yep
[15:06:15] <mathieuancelin> I'll do that
[15:06:23] <mathieuancelin> pmuir: the list seems okay
[15:06:35] <pmuir> mathieuancelin: cool
[15:06:59] <mathieuancelin> then we'll have to fix the issues :)
[15:08:08] <alesj> i think we have a plan :-)
[15:09:44] <alesj> btw: what exactly do we put under the id then?
[15:10:03] <alesj> since looking at ModuleGroupSP it looks like TCCL is to coarse-grained
[15:10:13] <alesj> hence stuartdouglas also registers sub-classloaders
[15:10:31] *** oskutka has joined #weld-dev
[15:10:32] <alesj> which is something we cannot do per id
[15:12:57] <mathieuancelin> does the sub classloaders matters to identify singletons ?
[15:13:42] <alesj> the TCCL approach doersn't work in AS7
[15:13:51] <alesj> since the CL is not hierarchical
[15:13:57] <alesj> but modular / graph
[15:14:04] <mathieuancelin> yep, like OSGi :)
[15:14:08] <alesj> hence you cannot just go up up ? to the parent
[15:14:21] <alesj> and get the right container
[15:14:23] <alesj> so
[15:14:28] <alesj> yeah, like OSGi ;-)
[15:14:34] <alesj> i just wanna say
[15:14:40] <alesj> that probably just one id is not enough
[15:14:48] <mathieuancelin> maybe
[15:14:52] <alesj> we would need one per each CL
[15:14:56] <mathieuancelin> I'm building AS7 right
[15:14:57] <mathieuancelin> now
[15:15:04] <alesj> it could work w/o
[15:15:06] <alesj> as it does now
[15:15:15] <alesj> but since we already have id notion in place
[15:15:20] <alesj> let's make a proper use of it
[15:15:31] <mathieuancelin> yes it should work without changes
[15:15:37] <alesj> yes
[15:15:50] <alesj> but let's check anyway how to properly put this id notion into AS7 as well
[15:16:04] <alesj> i think for any issues stuartdouglas would be best to answer
[15:16:46] <mathieuancelin> I suppose there are integration tests in AS7 to check if CDI apps works well
[15:16:49] <mathieuancelin> ok
[15:17:00] <alesj> hmmm
[15:17:17] <alesj> dunno if we didn't just run CDI-TCK over it
[15:17:23] <alesj> and let Weld test AS7
[15:17:28] <alesj> not vice-versa
[15:17:44] <mathieuancelin> ok I'll try weld test after AS7 build
[15:17:50] <alesj> ok
[15:18:04] <mathieuancelin> hope it use the same artifacts
[15:18:09] <alesj> nah ....
[15:18:15] <alesj> i think you'll have problems :-)
[15:18:23] <alesj> since ARQ is not in-synch
[15:18:32] <alesj> hence i said I need to update that first
[15:18:43] <alesj> let me work on that this week
[15:18:49] <mathieuancelin> ok
[15:18:53] <mathieuancelin> no problem
[15:18:59] <alesj> and you try this manually for the moment :-)
[15:19:06] <mathieuancelin> ok
[15:19:13] <alesj> and i'll try and synch this till the end on the week
[15:19:22] <alesj> to get Weld on AS7 and upgraded ARQ
[15:19:36] <alesj> hence making it trvial for you to test then
[15:19:40] <mathieuancelin> ok
[15:19:50] <alesj> and for id notion and AS7
[15:19:55] <alesj> i think we can also wait
[15:19:58] <mathieuancelin> ok
[15:20:08] <alesj> and i'll check with stuartdouglas what can be done
[15:20:22] <alesj> as i would say we need to change the way we integrate a but
[15:20:25] <alesj> bit
[15:20:31] <alesj> to be per (sub)deployment
[15:21:11] <alesj> and drag id properly across integration
[15:22:13] <mathieuancelin> ok
[15:23:21] <alesj> anyway, that's for stuartdouglas to check :-)
[15:23:55] <mathieuancelin> :)
[15:24:37] *** kevinpollet has quit IRC
[15:25:20] *** rmartinelli has joined #weld-dev
[15:31:52] <mathieuancelin> Is there some planned deadline for Weld 1.2 ?
[15:32:40] *** kevinpollet has joined #weld-dev
[15:32:50] <alesj> just writing an email ;-)
[15:34:22] <mathieuancelin> :) ok
[15:34:24] <mathieuancelin> I'll wait
[15:39:31] *** jharting has quit IRC
[15:48:31] *** kevinpollet has quit IRC
[15:52:04] <mathieuancelin> erf
[15:52:09] <mathieuancelin> it's not working
[15:53:52] <alesj> not building for you?
[15:53:53] <alesj> or what?
[15:53:54] <mathieuancelin> the JSF integration has no acces to the ID
[15:54:21] <mathieuancelin> because the listener is instantiated by the container
[15:54:35] <mathieuancelin> same for servlet
[15:54:40] <mathieuancelin> or ejb
[15:55:19] <mathieuancelin> That's why we have default ID, etc ...
[15:55:34] <mathieuancelin> totally forgot about it
[15:56:03] <mathieuancelin> (I'm trying with weld example apps)
[15:56:45] *** kevinpollet has joined #weld-dev
[16:01:23] <alesj> :-)
[16:01:33] *** magesh has joined #weld-dev
[16:02:54] <mathieuancelin> I'll try to find a way
[16:05:58] <pmuir> mathieuancelin: :-)
[16:22:34] *** mbg has joined #weld-dev
[16:24:05] *** mbg has quit IRC
[16:28:24] *** mbg has joined #weld-dev
[16:29:57] *** mbg1 has joined #weld-dev
[16:38:18] *** oskutka has quit IRC
[16:45:26] *** mbg has quit IRC
[16:45:49] *** oskutka has joined #weld-dev
[16:46:33] *** matthieuclochard has quit IRC
[17:28:35] *** magesh has quit IRC
[17:42:23] *** mbg1 has quit IRC
[17:49:02] <aslak> alesj, you never merged my arq_beta1 weld-core branch upstream ?
[17:49:05] <aslak> https://github.com/aslakknutsen/weld-core/tree/arq_beta1
[17:49:42] <alesj> aslak: yes, on my todo list
[17:49:49] <alesj> we have some branch
[17:49:55] <alesj> with all merged changes
[17:50:02] <alesj> but we had to do 1.1.2.Final in between
[17:50:04] <alesj> hence delayed
[17:50:08] <aslak> alesj, aa ok..
[17:50:08] <alesj> then forgot :-(
[17:50:48] <aslak> alesj, was just looking for some @ShouldThowException examples for Pete, but couldn't find them in master.. :)
[17:50:58] <aslak> alesj, it's merged in the arq_update branch ?
[17:51:46] <alesj> there are 3 arq_update branhes
[17:51:54] <alesj> your, stuartdouglas and mine
[17:52:01] <alesj> we need to see which one is the latest :-)
[17:52:06] <aslak> alesj, yea, and stuart has the latest i think.. :)
[17:53:40] <alesj> aslak: ok, i'll try to merge this asap
[17:53:48] <aslak> alesj, hmm.. the beta1 branch is not included there tho
[17:53:48] <alesj> as there are other waiting for this as well :-)
[17:54:11] <alesj> beta1 of ARQ?
[17:55:15] <aslak> alesj, the branch was called arq_beta1, it upgraded from alpha5 to beta1, and migrated more test cases over to arq, specifically the ones that needed the deployment exception features
[17:56:47] <aslak> alesj, https://github.com/aslakknutsen/weld-core/commits/arq_beta1
[17:57:20] <aslak> alesj, i think you can skip the "Update to new .." commit, but include the "Convert tests from .." one
[18:02:50] *** cbrock has joined #weld-dev
[18:03:19] <alesj> aslak: i'll ping you once i have merged with arq_up branch
[18:03:33] <alesj> if you can then check if something else needs fixing as well
[18:03:33] <alesj> ok?
[18:03:35] <alesj> aslak: ^
[18:05:58] <aslak> alesj, sure
[18:09:24] *** oskutka has quit IRC
[18:13:49] *** mbg has joined #weld-dev
[21:28:34] *** echelog-2 has joined #weld-dev
[22:09:39] *** alesj has joined #weld-dev
[22:18:30] *** rmartinelli has quit IRC
[22:20:24] *** aslak has quit IRC
[23:01:58] *** kevinpollet has quit IRC
[23:32:37] *** kevinpollet has joined #weld-dev
[23:47:04] *** kevinpollet has quit IRC
[23:59:09] *** cbrock has quit IRC





top