Menu
▾
▴
fennel-developers — Mailing list for all Fennel developers
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(5) |
Oct
(7) |
Nov
(5) |
Dec
(12) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1) |
Feb
(8) |
Mar
(4) |
Apr
|
May
(1) |
Jun
(14) |
Jul
|
Aug
(4) |
Sep
(7) |
Oct
(1) |
Nov
|
Dec
|
| 2007 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
(2) |
Jul
(7) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(7) |
| 2008 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
(2) |
Jun
(15) |
Jul
|
Aug
(8) |
Sep
(2) |
Oct
(10) |
Nov
(5) |
Dec
(10) |
| 2009 |
Jan
(7) |
Feb
(1) |
Mar
(10) |
Apr
(24) |
May
(2) |
Jun
(3) |
Jul
(4) |
Aug
(13) |
Sep
(6) |
Oct
(2) |
Nov
(9) |
Dec
(12) |
| 2010 |
Jan
(4) |
Feb
|
Mar
(7) |
Apr
(2) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(1) |
| 2011 |
Jan
(4) |
Feb
(1) |
Mar
(3) |
Apr
(2) |
May
(3) |
Jun
(13) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
|
From: Atri S. <atr...@gm...> - 2013-10-23 17:46:18
|
Thanks a ton,I will have a look and ask if required. Atri Sent from my iPad > On 23-Oct-2013, at 23:09, John Sichi <js...@gm...> wrote: > >> On Tue, Oct 22, 2013 at 10:53 AM, Atri Sharma <atr...@gm...> wrote: >> Can we revive the development? I am really looking forward to working on fennel. > > Speaking for myself, I'm no longer working on it, but if you have specific questions about how something works, I can try to answer. > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Fennel-developers mailing list > Fen...@li... > https://lists.sourceforge.net/lists/listinfo/fennel-developers |
|
From: John S. <js...@gm...> - 2013-10-23 17:39:11
|
On Tue, Oct 22, 2013 at 10:53 AM, Atri Sharma <atr...@gm...> wrote: > Can we revive the development? I am really looking forward to working on > fennel. > Speaking for myself, I'm no longer working on it, but if you have specific questions about how something works, I can try to answer. |
|
From: Atri S. <atr...@gm...> - 2013-10-22 17:53:49
|
Hi JVS, No issues. Can we revive the development? I am really looking forward to working on fennel. Regards, Atri Sent from my iPad > On 22-Oct-2013, at 23:18, John Sichi <js...@gm...> wrote: > >> On Sun, Oct 20, 2013 at 8:31 PM, Atri Sharma <atr...@gm...> wrote: >> Hi all, >> >> I am a C and C++ developer with experience in database internals and data management. I have been working with PostgreSQL project for some time now and would like to additionally contribute to Fennel. >> >> I would be interested in root level storage optimisation. > > Hey Atri, > > I think all active open source development on the project has tapered off (there may still be private development ongoing). If you want to fork it on github, I think the latest code is here: > > https://github.com/LucidDB/luciddb > > JVS > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Fennel-developers mailing list > Fen...@li... > https://lists.sourceforge.net/lists/listinfo/fennel-developers |
|
From: John S. <js...@gm...> - 2013-10-22 17:48:56
|
On Sun, Oct 20, 2013 at 8:31 PM, Atri Sharma <atr...@gm...> wrote: > Hi all, > > I am a C and C++ developer with experience in database internals and data > management. I have been working with PostgreSQL project for some time now > and would like to additionally contribute to Fennel. > > I would be interested in root level storage optimisation. > > Hey Atri, I think all active open source development on the project has tapered off (there may still be private development ongoing). If you want to fork it on github, I think the latest code is here: https://github.com/LucidDB/luciddb JVS |
|
From: Atri S. <atr...@gm...> - 2013-10-21 03:31:41
|
Hi all, I am a C and C++ developer with experience in database internals and data management. I have been working with PostgreSQL project for some time now and would like to additionally contribute to Fennel. I would be interested in root level storage optimisation. Please suggest. Regards, Atri Sent from my iPad |
|
From: <ren...@re...> - 2012-03-12 16:33:37
|
Hi John, This email is to inform you that you have one or more domain names registered with us, which are about to expire. Domain(s): ---------------------------------------------- eigenbase.com - expires on March 13, 2012 If you are reading this email, it means that we have exhausted our resources in attempting to contact you. As a courtesy we are sending you this email as a final reminder. Please follow this link to renew your domain(s): http://www.registar.com/renew.shtml Please do not wait until the last minute to renew your domain name and risk losing it. Domain names that are not renewed will be eventually put back into the general pool for anyone to register. The additional years you purchase will be added to your existing domain name's expiration date (not the date you renew it on). After you are finished renewing your domain name, please take a moment to verify that the contact information associated with your domain name is current. You may log into your domain name control panel from here: http://www.registar.com/cp.shtml If you have not yet taken advantage of free Google Apps email, which is included as part of your domain name registration, then please open a ticket using our Contact Us form and let us know. Contact Us Form: http://www.registar.com/contact.shtml ****************************************************** Did you know that regiSTAR.com now offers Web Hosting? Signup today for as little as $8.25/mo.! For more information visit: http://www.registar.com/hosting.shtml As always, we appreciate your business and are here to assist you should you need it. Thank you for choosing regiSTAR.com! Your regiSTAR.com Support Team su...@re... http://www.regiSTAR.com 888-858-6258 http://www.RegiSTAR.com - The STAR of Registrars - su...@re... |
|
From: Richard N. <ric...@sq...> - 2011-08-29 05:47:34
|
Nick: We're currently holding at 4.1.2 also, but have no objection to moving forward. I think all our developers have long-since moved on to much newer versions, and I am pretty sure we can reliably compile and run at 4.5.something. So unless you're heading toward the bleeding edge, I think we'll have no issues with that. --Chard On 8/28/2011 2:36 PM, Nicholas Goodman wrote: > Currently we're building LucidDB with gcc 4.1.2 on both 32 and 64 bit Linux. > > Since we've recently upgraded our STLPort and Boost libs I'm guessing we can probably roll forward. We're going to do some complete test builds but I thought I'd ask what other current versions (linux/gcc version) others have built with 100% acceptance on for Fennel. > > We're considering moving forward (to at least 4.3.x) for the 0.9.4 production release. > > Nick |
|
From: Nicholas G. <ngo...@dy...> - 2011-08-28 21:36:39
|
Currently we're building LucidDB with gcc 4.1.2 on both 32 and 64 bit Linux. Since we've recently upgraded our STLPort and Boost libs I'm guessing we can probably roll forward. We're going to do some complete test builds but I thought I'd ask what other current versions (linux/gcc version) others have built with 100% acceptance on for Fennel. We're considering moving forward (to at least 4.3.x) for the 0.9.4 production release. Nick |
|
From: Sunil M. <su...@sq...> - 2011-06-23 17:24:37
|
Hi Nik, There was one change (14391) that was left out in the integration yesterday. The new change# is 14401. Regards, Sunil On Thu, Jun 23, 2011 at 9:17 AM, Nicholas Goodman < ngo...@ba...> wrote: > I noticed you did this! Thanks Sunil! > > There seems to remain an issue in the packaging phase: > > + cp 'RmiJdbc/dist/lib/*.jar' /build/hudson_home/jobs/open_dev_initbuild/workspace/label/lin32/farrago/dist/tmp/eigenbase-0.0.0.14400/lib > cp: cannot stat `RmiJdbc/dist/lib/*.jar': No such file or directory > > Full logs are here: > http://build.dynamobi.com/job/open_dev_initbuild/label=lin32/48/console > > Thanks! Great to finally get RmiJdbc ELIMINATED!!!! Yaaay! > > On Jun 21, 2011, at 3:10 PM, Sunil Mujumdar wrote: > > ok. will integrate soon. (no later than tomorrow morning). > > Sunil. > > On Tue, Jun 21, 2011 at 2:32 PM, Julian Hyde <jul...@sq...>wrote: > >> ** >> Agreed. There are no other blockers. >> >> Sunil, >> >> Can you please integrate the FRG-403 fix (14388, 14389) to //open/dev. >> Then mark FRG-403 fixed. >> >> Julian >> >> ------------------------------ >> *From:* Nicholas Goodman [mailto:ngo...@ba...] >> *Sent:* Tuesday, June 21, 2011 1:30 PM >> *To:* far...@ei... >> *Cc:* fen...@ei... >> *Subject:* Re: [Farrago-developers] [Fennel-developers] Bug Burn Down for >> 0.9.4 >> >> An update on our march towards the 0.9.4 release. >> >> We've pulled all the DT/DEV integrations into our branch, did a few >> patches/resolutions (minimal, mostly from some cosmetic issues) and then >> integrated all our changes from dy/dev up to open/dev. >> Eigenchange 14395 >> http://p4webhost.eigenbase.org:8080/@md=d&cd=//open/&c=q2V@/14395?ac=10 >> Test Report: >> >> http://build.dynamobi.com/job/open_dev_initbuild/label=lin64/47/testReport/ >> >> From my perspective we'd get a +1 from me for a release as soon as the 3 >> tests in FRG-420 are renabled and pass, and FRG-422 is resolved. In my >> opinion, FRG-403 shouldn't block our release (plus I think I saw Hunter >> already did some work on this). >> >> If anyone disagrees on these two issues (FRG-420, FRG-422) as the only >> blockers for a 0.9.4 release speak NOW. :) >> >> Nick >> >> On Jun 14, 2011, at 2:36 PM, Kevin Secretan wrote: >> >> With http://jira.eigenbase.org/browse/FRG-420 there are three unit tests >> commented out in Farrago's build.xml, two of which came from the dt >> integration. The third one is due to the actual unicode character in the >> test rather than an escaped unicode number. I think we may have discussed >> this already, and the problem was with the testing framework? >> >> http://jira.eigenbase.org/browse/FRG-422 documents the problem with >> running queries from sqllineClient rather than sqllineEngine. The full stack >> trace is being printed out on error. >> >> http://jira.eigenbase.org/browse/FRG-403 is getting rid of RmiJdbc, >> apparently on the burner for a while. >> >> >> > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > > http://p.sf.net/sfu/ephox-dev2dev_______________________________________________ > Fennel-developers mailing list > Fen...@li... > https://lists.sourceforge.net/lists/listinfo/fennel-developers > > > |
|
From: Nicholas G. <ngo...@ba...> - 2011-06-23 16:17:37
|
I noticed you did this! Thanks Sunil! There seems to remain an issue in the packaging phase: + cp 'RmiJdbc/dist/lib/*.jar' /build/hudson_home/jobs/open_dev_initbuild/workspace/label/lin32/farrago/dist/tmp/eigenbase-0.0.0.14400/lib cp: cannot stat `RmiJdbc/dist/lib/*.jar': No such file or directory Full logs are here: http://build.dynamobi.com/job/open_dev_initbuild/label=lin32/48/console Thanks! Great to finally get RmiJdbc ELIMINATED!!!! Yaaay! On Jun 21, 2011, at 3:10 PM, Sunil Mujumdar wrote: > ok. will integrate soon. (no later than tomorrow morning). > > Sunil. > > On Tue, Jun 21, 2011 at 2:32 PM, Julian Hyde <jul...@sq...> wrote: > Agreed. There are no other blockers. > > Sunil, > > Can you please integrate the FRG-403 fix (14388, 14389) to //open/dev. Then mark FRG-403 fixed. > > Julian > > From: Nicholas Goodman [mailto:ngo...@ba...] > Sent: Tuesday, June 21, 2011 1:30 PM > To: far...@ei... > Cc: fen...@ei... > Subject: Re: [Farrago-developers] [Fennel-developers] Bug Burn Down for 0.9.4 > > An update on our march towards the 0.9.4 release. > > We've pulled all the DT/DEV integrations into our branch, did a few patches/resolutions (minimal, mostly from some cosmetic issues) and then integrated all our changes from dy/dev up to open/dev. > Eigenchange 14395 > http://p4webhost.eigenbase.org:8080/@md=d&cd=//open/&c=q2V@/14395?ac=10 > Test Report: > http://build.dynamobi.com/job/open_dev_initbuild/label=lin64/47/testReport/ > > From my perspective we'd get a +1 from me for a release as soon as the 3 tests in FRG-420 are renabled and pass, and FRG-422 is resolved. In my opinion, FRG-403 shouldn't block our release (plus I think I saw Hunter already did some work on this). > > If anyone disagrees on these two issues (FRG-420, FRG-422) as the only blockers for a 0.9.4 release speak NOW. :) > > Nick > > On Jun 14, 2011, at 2:36 PM, Kevin Secretan wrote: > >> With http://jira.eigenbase.org/browse/FRG-420 there are three unit tests commented out in Farrago's build.xml, two of which came from the dt integration. The third one is due to the actual unicode character in the test rather than an escaped unicode number. I think we may have discussed this already, and the problem was with the testing framework? >> >> http://jira.eigenbase.org/browse/FRG-422 documents the problem with running queries from sqllineClient rather than sqllineEngine. The full stack trace is being printed out on error. >> >> http://jira.eigenbase.org/browse/FRG-403 is getting rid of RmiJdbc, apparently on the burner for a while. > > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev_______________________________________________ > Fennel-developers mailing list > Fen...@li... > https://lists.sourceforge.net/lists/listinfo/fennel-developers |
|
From: Sunil M. <su...@sq...> - 2011-06-21 22:10:55
|
ok. will integrate soon. (no later than tomorrow morning). Sunil. On Tue, Jun 21, 2011 at 2:32 PM, Julian Hyde <jul...@sq...>wrote: > ** > Agreed. There are no other blockers. > > Sunil, > > Can you please integrate the FRG-403 fix (14388, 14389) to //open/dev. Then > mark FRG-403 fixed. > > Julian > > ------------------------------ > *From:* Nicholas Goodman [mailto:ngo...@ba...] > *Sent:* Tuesday, June 21, 2011 1:30 PM > *To:* far...@ei... > *Cc:* fen...@ei... > *Subject:* Re: [Farrago-developers] [Fennel-developers] Bug Burn Down for > 0.9.4 > > An update on our march towards the 0.9.4 release. > > We've pulled all the DT/DEV integrations into our branch, did a few > patches/resolutions (minimal, mostly from some cosmetic issues) and then > integrated all our changes from dy/dev up to open/dev. > Eigenchange 14395 > http://p4webhost.eigenbase.org:8080/@md=d&cd=//open/&c=q2V@/14395?ac=10 > Test Report: > http://build.dynamobi.com/job/open_dev_initbuild/label=lin64/47/testReport/ > > From my perspective we'd get a +1 from me for a release as soon as the 3 > tests in FRG-420 are renabled and pass, and FRG-422 is resolved. In my > opinion, FRG-403 shouldn't block our release (plus I think I saw Hunter > already did some work on this). > > If anyone disagrees on these two issues (FRG-420, FRG-422) as the only > blockers for a 0.9.4 release speak NOW. :) > > Nick > > On Jun 14, 2011, at 2:36 PM, Kevin Secretan wrote: > > With http://jira.eigenbase.org/browse/FRG-420 there are three unit tests > commented out in Farrago's build.xml, two of which came from the dt > integration. The third one is due to the actual unicode character in the > test rather than an escaped unicode number. I think we may have discussed > this already, and the problem was with the testing framework? > > http://jira.eigenbase.org/browse/FRG-422 documents the problem with > running queries from sqllineClient rather than sqllineEngine. The full stack > trace is being printed out on error. > > http://jira.eigenbase.org/browse/FRG-403 is getting rid of RmiJdbc, > apparently on the burner for a while. > > > |
|
From: Julian H. <jul...@sq...> - 2011-06-21 21:39:09
|
Agreed. There are no other blockers. Sunil, Can you please integrate the FRG-403 fix (14388, 14389) to //open/dev. Then mark FRG-403 fixed. Julian _____ From: Nicholas Goodman [mailto:ngo...@ba...] Sent: Tuesday, June 21, 2011 1:30 PM To: far...@ei... Cc: fen...@ei... Subject: Re: [Farrago-developers] [Fennel-developers] Bug Burn Down for 0.9.4 An update on our march towards the 0.9.4 release. We've pulled all the DT/DEV integrations into our branch, did a few patches/resolutions (minimal, mostly from some cosmetic issues) and then integrated all our changes from dy/dev up to open/dev. Eigenchange 14395 http://p4webhost.eigenbase.org:8080/@md=d <http://p4webhost.eigenbase.org:8080/@md=d&cd=//open/&c=q2V@/14395?ac=10> &cd=//open/&c=q2V@/14395?ac=10 Test Report: http://build.dynamobi.com/job/open_dev_initbuild/label=lin64/47/testReport/ >From my perspective we'd get a +1 from me for a release as soon as the 3 tests in FRG-420 are renabled and pass, and FRG-422 is resolved. In my opinion, FRG-403 shouldn't block our release (plus I think I saw Hunter already did some work on this). If anyone disagrees on these two issues (FRG-420, FRG-422) as the only blockers for a 0.9.4 release speak NOW. :) Nick On Jun 14, 2011, at 2:36 PM, Kevin Secretan wrote: With http://jira.eigenbase.org/browse/FRG-420 there are three unit tests commented out in Farrago's build.xml, two of which came from the dt integration. The third one is due to the actual unicode character in the test rather than an escaped unicode number. I think we may have discussed this already, and the problem was with the testing framework? http://jira.eigenbase.org/browse/FRG-422 documents the problem with running queries from sqllineClient rather than sqllineEngine. The full stack trace is being printed out on error. http://jira.eigenbase.org/browse/FRG-403 is getting rid of RmiJdbc, apparently on the burner for a while. |
|
From: Nicholas G. <ngo...@ba...> - 2011-06-21 20:35:49
|
An update on our march towards the 0.9.4 release. We've pulled all the DT/DEV integrations into our branch, did a few patches/resolutions (minimal, mostly from some cosmetic issues) and then integrated all our changes from dy/dev up to open/dev. Eigenchange 14395 http://p4webhost.eigenbase.org:8080/@md=d&cd=//open/&c=q2V@/14395?ac=10 Test Report: http://build.dynamobi.com/job/open_dev_initbuild/label=lin64/47/testReport/ From my perspective we'd get a +1 from me for a release as soon as the 3 tests in FRG-420 are renabled and pass, and FRG-422 is resolved. In my opinion, FRG-403 shouldn't block our release (plus I think I saw Hunter already did some work on this). If anyone disagrees on these two issues (FRG-420, FRG-422) as the only blockers for a 0.9.4 release speak NOW. :) Nick On Jun 14, 2011, at 2:36 PM, Kevin Secretan wrote: > With http://jira.eigenbase.org/browse/FRG-420 there are three unit tests commented out in Farrago's build.xml, two of which came from the dt integration. The third one is due to the actual unicode character in the test rather than an escaped unicode number. I think we may have discussed this already, and the problem was with the testing framework? > > http://jira.eigenbase.org/browse/FRG-422 documents the problem with running queries from sqllineClient rather than sqllineEngine. The full stack trace is being printed out on error. > > http://jira.eigenbase.org/browse/FRG-403 is getting rid of RmiJdbc, apparently on the burner for a while. |
|
From: Kevin S. <kse...@dy...> - 2011-06-14 21:36:16
|
Woops, missed the reply-all button... ---------- Forwarded message ---------- From: Kevin Secretan <kse...@dy...> Date: Tue, Jun 14, 2011 at 2:31 PM Subject: Re: [Fennel-developers] Bug Burn Down for 0.9.4 To: fen...@ei... Nick has created a set of filters for various bugs that are viewable on the home page: http://jira.eigenbase.org/secure/Dashboard.jspa <http://jira.eigenbase.org/secure/Dashboard.jspa>Here's a run down of a few I think are important (in no particular order): <http://jira.eigenbase.org/secure/Dashboard.jspa>With http://jira.eigenbase.org/browse/FRG-420 there are three unit tests commented out in Farrago's build.xml, two of which came from the dt integration. The third one is due to the actual unicode character in the test rather than an escaped unicode number. I think we may have discussed this already, and the problem was with the testing framework? http://jira.eigenbase.org/browse/FRG-422 documents the problem with running queries from sqllineClient rather than sqllineEngine. The full stack trace is being printed out on error. http://jira.eigenbase.org/browse/FRG-403 is getting rid of RmiJdbc, apparently on the burner for a while. On Mon, Jun 13, 2011 at 4:57 PM, Nicholas Goodman <ngo...@dy...>wrote: > Kevin and I will be spending much of the next couple of weeks squashing > bugs in preparation for a 0.9.4 release. For the most part, things appear > to be stable; we've integrated the latest and greatest from //open/dev to > our branch which includes Sunil's/Hunters integrations from dt/dev to > open/dev. > > Most of our initial issues encountered are some vJDBC upgrade > peculiarities, some packaging issues (we both made changes to version and > packaging), and then some disabled unit tests which need to be resolved > prior to release. Kevin and I will be posting the issues we find to Jira, > and then also emailing this list with requests for help with Jiras - ie, we > may request help resolving issues caused by changes from the dt/dev branch. > > Now, since this is the first time we've done this integration work, I have > a question for the list: We have a "stable" build in our branch; we'd like > to push it up, even though some unit tests failed and have been disabled, up > to //open/dev so that we all can pitch in on bug fixes/patches. OK? > > We will push an "almost" baked release in the next few days up to > //open/dev and then we can all spend the next few weeks patching/fixing on > //open/dev. Let us know if anyone sees an issue with that. > > Nick > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Fennel-developers mailing list > Fen...@li... > https://lists.sourceforge.net/lists/listinfo/fennel-developers > |
|
From: Kevin S. <kse...@dy...> - 2011-06-14 21:31:28
|
Nick has created a set of filters for various bugs that are viewable on the home page: http://jira.eigenbase.org/secure/Dashboard.jspa <http://jira.eigenbase.org/secure/Dashboard.jspa>Here's a run down of a few I think are important (in no particular order): <http://jira.eigenbase.org/secure/Dashboard.jspa>With http://jira.eigenbase.org/browse/FRG-420 there are three unit tests commented out in Farrago's build.xml, two of which came from the dt integration. The third one is due to the actual unicode character in the test rather than an escaped unicode number. I think we may have discussed this already, and the problem was with the testing framework? http://jira.eigenbase.org/browse/FRG-422 documents the problem with running queries from sqllineClient rather than sqllineEngine. The full stack trace is being printed out on error. http://jira.eigenbase.org/browse/FRG-403 is getting rid of RmiJdbc, apparently on the burner for a while. On Mon, Jun 13, 2011 at 4:57 PM, Nicholas Goodman <ngo...@dy...>wrote: > Kevin and I will be spending much of the next couple of weeks squashing > bugs in preparation for a 0.9.4 release. For the most part, things appear > to be stable; we've integrated the latest and greatest from //open/dev to > our branch which includes Sunil's/Hunters integrations from dt/dev to > open/dev. > > Most of our initial issues encountered are some vJDBC upgrade > peculiarities, some packaging issues (we both made changes to version and > packaging), and then some disabled unit tests which need to be resolved > prior to release. Kevin and I will be posting the issues we find to Jira, > and then also emailing this list with requests for help with Jiras - ie, we > may request help resolving issues caused by changes from the dt/dev branch. > > Now, since this is the first time we've done this integration work, I have > a question for the list: We have a "stable" build in our branch; we'd like > to push it up, even though some unit tests failed and have been disabled, up > to //open/dev so that we all can pitch in on bug fixes/patches. OK? > > We will push an "almost" baked release in the next few days up to > //open/dev and then we can all spend the next few weeks patching/fixing on > //open/dev. Let us know if anyone sees an issue with that. > > Nick > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Fennel-developers mailing list > Fen...@li... > https://lists.sourceforge.net/lists/listinfo/fennel-developers > |
|
From: Nicholas G. <ngo...@dy...> - 2011-06-13 23:58:09
|
Kevin and I will be spending much of the next couple of weeks squashing bugs in preparation for a 0.9.4 release. For the most part, things appear to be stable; we've integrated the latest and greatest from //open/dev to our branch which includes Sunil's/Hunters integrations from dt/dev to open/dev. Most of our initial issues encountered are some vJDBC upgrade peculiarities, some packaging issues (we both made changes to version and packaging), and then some disabled unit tests which need to be resolved prior to release. Kevin and I will be posting the issues we find to Jira, and then also emailing this list with requests for help with Jiras - ie, we may request help resolving issues caused by changes from the dt/dev branch. Now, since this is the first time we've done this integration work, I have a question for the list: We have a "stable" build in our branch; we'd like to push it up, even though some unit tests failed and have been disabled, up to //open/dev so that we all can pitch in on bug fixes/patches. OK? We will push an "almost" baked release in the next few days up to //open/dev and then we can all spend the next few weeks patching/fixing on //open/dev. Let us know if anyone sees an issue with that. Nick |
|
From: Julian H. <jul...@sq...> - 2011-06-07 00:00:48
|
Nick wrote: > Thanks Sunil... we're in the process of doing a full > integration down (dev to dy/dev), verifying 100% coverage and > then we'll integrate our stuff up and we'll post to the lists as well. I've just checked in a further integration from //open/dt/dev to //open/dev. This one consists only of cosmetic changes, regarding how multi-line parameter and argument lists are indented. (At some point I will update checkFile to check the rule.) I recommend that you integrate it over to //open/dy/dev also. Julian |
|
From: Nicholas G. <ngo...@dy...> - 2011-06-06 22:59:34
|
On Jun 6, 2011, at 3:12 PM, Sunil Mujumdar wrote: > This change essentially includes Chard's changes with services for SQL/MED, LURQL, and SqlAdvisor. Thanks Sunil... we're in the process of doing a full integration down (dev to dy/dev), verifying 100% coverage and then we'll integrate our stuff up and we'll post to the lists as well. Nick |
|
From: Sunil M. <su...@sq...> - 2011-06-06 22:12:31
|
FYI. This change essentially includes Chard's changes with services for SQL/MED, LURQL, and SqlAdvisor. Regards, Sunil |
|
From: Sunil M. <su...@sq...> - 2011-06-02 18:16:26
|
Hello All, I started integration from //open/dt/dev branch to //open/dev branch. I will keep you all posted about the progress. More later today. Regards, Sunil On Wed, Jun 1, 2011 at 8:11 PM, Sunil Mujumdar <su...@sq...> wrote: > Hi Nick, > > I am the integration monkey for SQLstream team for this month. I will get > back to you about our plans to integrate //open/dt/dev branch back to > //open/dev latest by noon tomorrow. I will try my best to integrate so that > your release incorporates dt/dev changes by friday. > > Regards, > Sunil > > > On Tue, May 31, 2011 at 1:58 PM, Nicholas Goodman <ngo...@dy...>wrote: > >> Once we get a fully integrated, tested, and spot checked //open/dev we >> will work through the release procedure here: >> http://pub.eigenbase.org/wiki/ReleaseProcedure >> >> We will start our integration from dy/dev up to open/dev this Friday. It >> would be helpful if dt/dev integration up could be complete by then, but >> it's not a prerequisite but it would be much easier to have a clean, 100% >> passing open/dev prior to us integrating up. >> >> We're still trying to get our windows build machines re-imaged, but will >> do that prior to release. >> >> Our branch contains a few modifications to release packaging scripts that >> will be in our integration up. In particular, we modified the scripts to >> allow for: >> - Releases can be built from any branch, not just //open/dev. This is >> helpful when we're doing milestone releases directly from the dy/dev branch >> of LucidDB (or patches for customers). >> - Release point releases are now a string (RC1 or M1 or GA or ... >> whatever). I'm not sure how dependent Aspen is on FarragoReleaseProperties >> class, but we've changed the datatype of point release to StringProperty >> instead of IntegerProperty. Comments/concerns/flames welcomed. >> >> We had to revert (on our branch) JVS's generated transient JMI >> implementation because of issues with packaging for a release (Enki + >> transient classes). We intend to do release with the memory only >> implementation (same one present in 0.9.3) and work on re-enabling post >> 0.9.4. However, if anyone has time to sort out the release packaging of >> this change prior to a 0.9.4 release we'd welcome the help. >> >> Nick > > > |
|
From: Sunil M. <su...@sq...> - 2011-06-02 03:16:55
|
Hi Nick, I am the integration monkey for SQLstream team for this month. I will get back to you about our plans to integrate //open/dt/dev branch back to //open/dev latest by noon tomorrow. I will try my best to integrate so that your release incorporates dt/dev changes by friday. Regards, Sunil On Tue, May 31, 2011 at 1:58 PM, Nicholas Goodman <ngo...@dy...>wrote: > Once we get a fully integrated, tested, and spot checked //open/dev we will > work through the release procedure here: > http://pub.eigenbase.org/wiki/ReleaseProcedure > > We will start our integration from dy/dev up to open/dev this Friday. It > would be helpful if dt/dev integration up could be complete by then, but > it's not a prerequisite but it would be much easier to have a clean, 100% > passing open/dev prior to us integrating up. > > We're still trying to get our windows build machines re-imaged, but will do > that prior to release. > > Our branch contains a few modifications to release packaging scripts that > will be in our integration up. In particular, we modified the scripts to > allow for: > - Releases can be built from any branch, not just //open/dev. This is > helpful when we're doing milestone releases directly from the dy/dev branch > of LucidDB (or patches for customers). > - Release point releases are now a string (RC1 or M1 or GA or ... > whatever). I'm not sure how dependent Aspen is on FarragoReleaseProperties > class, but we've changed the datatype of point release to StringProperty > instead of IntegerProperty. Comments/concerns/flames welcomed. > > We had to revert (on our branch) JVS's generated transient JMI > implementation because of issues with packaging for a release (Enki + > transient classes). We intend to do release with the memory only > implementation (same one present in 0.9.3) and work on re-enabling post > 0.9.4. However, if anyone has time to sort out the release packaging of > this change prior to a 0.9.4 release we'd welcome the help. > > Nick |
|
From: Nicholas G. <ngo...@dy...> - 2011-05-31 20:58:37
|
Once we get a fully integrated, tested, and spot checked //open/dev we will work through the release procedure here: http://pub.eigenbase.org/wiki/ReleaseProcedure We will start our integration from dy/dev up to open/dev this Friday. It would be helpful if dt/dev integration up could be complete by then, but it's not a prerequisite but it would be much easier to have a clean, 100% passing open/dev prior to us integrating up. We're still trying to get our windows build machines re-imaged, but will do that prior to release. Our branch contains a few modifications to release packaging scripts that will be in our integration up. In particular, we modified the scripts to allow for: - Releases can be built from any branch, not just //open/dev. This is helpful when we're doing milestone releases directly from the dy/dev branch of LucidDB (or patches for customers). - Release point releases are now a string (RC1 or M1 or GA or ... whatever). I'm not sure how dependent Aspen is on FarragoReleaseProperties class, but we've changed the datatype of point release to StringProperty instead of IntegerProperty. Comments/concerns/flames welcomed. We had to revert (on our branch) JVS's generated transient JMI implementation because of issues with packaging for a release (Enki + transient classes). We intend to do release with the memory only implementation (same one present in 0.9.3) and work on re-enabling post 0.9.4. However, if anyone has time to sort out the release packaging of this change prior to a 0.9.4 release we'd welcome the help. Nick |
|
From: Julian H. <jul...@sq...> - 2011-05-23 22:38:44
|
I have had reports of "out of disk space" errors from the eigenbase perforce server. I believe these are now fixed. If you experience any further problems, please let me know. Julian |
|
From: Julian H. <jh...@pe...> - 2011-05-23 21:23:00
|
I have had reports of "out of disk space" errors from the eigenbase perforce server. I believe these are now fixed. If you experience any further problems, please let me know. Julian |
|
From: Julian H. <jul...@sq...> - 2011-04-18 21:30:46
|
If I may clarify. The alignment at issue here is the length of the tuple. Fennel aligns 8 byte integer fields to 8 byte boundaries, 4 byte integer fields to 4 byte boundaries, et cetera, and we are not proposing to change that. However, consider a tuple consisting of an 8 byte integer and a 4 byte integer. On a 32 bit platform, that tuple would be 12 bytes long; on a 64 bits, it would be 16. We would like to be able to specify alignment=8, that the tuple's length would be padded to 16 even on a 32 bit machine. Julian > -----Original Message----- > From: Hunter Payne [mailto:hun...@sq...] > Sent: Monday, April 18, 2011 2:20 PM > To: fen...@ei... > Subject: Tuple Accessor alignment change > > I've been working on some 32 v 64 bit alignment issues in a networking > stack that uses the Fennel TupleAccessor. The Java version of this > class has a constructor argument that allows it to function > in both a 4 > byte aligned and 8 byte aligned mode. However, the > constructor in the > C++ version of this class has no arguments and only functions in the > alignment of the native hardware. > > I want to add the ability to handle different byte alignments to the > C++ TupleAccessor. By far, the easiest way to do this is to pull > alignRoundUp() from fennel/common/CommonPreamble.h and put it in > TupleAccessor and fix it to mirror the Java alignRoundUp() > method. Then > add another constructor that takes an TupleAlignment enum and > allows the > TupleAccessor to handle both 4 and 8 byte alignments. > > There has been some argument to how this value should be set > by the XOs > that use TupleAccessor. For now, that wouldn't change except for XOs > that explicitly changed how they constructed their TupleAccessors. > > Julian has argued that the alignment argument should be added to > compute() instead as an optional argument. This could create issues > with different C++ compilers given that this would mean that the last > two arguments to compute() would both be optional. > > Questions? Thoughts? > > Hunter > > |
4 messages has been excluded from this view by a project administrator.