From: Dean M. B. <mik...@gm...> - 2010-12-03 04:34:58
|
Hi Guys, I think the easiest way to minimize the compile time cost would be to move the Spirit.Qi based parser out to a .cpp and just build and external lib. I'll try to make that happen locally and see how far that goes, and I'll update everyone on what that's going to look like for 0.9 soon as I'm done. Comments, feedback, violent reactions, etc. would be most appreciated. HTH -- Dean Michael Berris deanberris.com |
From: Dean M. B. <mik...@gm...> - 2010-12-03 08:24:08
|
On Fri, Dec 3, 2010 at 12:34 PM, Dean Michael Berris <mik...@gm...> wrote: > Hi Guys, > > I think the easiest way to minimize the compile time cost would be to > move the Spirit.Qi based parser out to a .cpp and just build and > external lib. I'll try to make that happen locally and see how far > that goes, and I'll update everyone on what that's going to look like > for 0.9 soon as I'm done. > As promised, here's the associated commit on the 0.9-devel branch -- hopefully the lower building and testing costs now will lower the barrier to usage of the library. Jeroen/Glyn, I had to make a lot of changes, and one of them is the removal of the references in the URI tuple handling. I'm not sure I did the right things here, but it would be greatly appreciated if both of you can take a look at what I've done. > Comments, feedback, violent reactions, etc. would be most appreciated. This is still definitely true, looking forward to what the people on the other side of the world will have to say. Thanks and I hope this helps. (Also, to those watching, 0.9 will not be a header-only release anymore, so the whole documentation will have to be overhauled. Help in that regard would really be appreciated.) -- Dean Michael Berris deanberris.com |
From: Dean M. B. <mik...@gm...> - 2010-12-03 08:26:54
|
On Fri, Dec 3, 2010 at 4:23 PM, Dean Michael Berris <mik...@gm...> wrote: > On Fri, Dec 3, 2010 at 12:34 PM, Dean Michael Berris > <mik...@gm...> wrote: >> Hi Guys, >> >> I think the easiest way to minimize the compile time cost would be to >> move the Spirit.Qi based parser out to a .cpp and just build and >> external lib. I'll try to make that happen locally and see how far >> that goes, and I'll update everyone on what that's going to look like >> for 0.9 soon as I'm done. >> > > As promised, here's the associated commit on the 0.9-devel branch -- > hopefully the lower building and testing costs now will lower the > barrier to usage of the library. > https://github.com/mikhailberis/cpp-netlib/commit/b74ce4c5deadaeb74d997919efea3141d71040cd shortened: http://goo.gl/HVDQb -- Dean Michael Berris deanberris.com |
From: Nelson, E. - 2 <eri...@ba...> - 2010-12-03 15:18:00
|
> Dean Michael Berris wrote on Thursday, December 02, 2010 11:35 PM > I think the easiest way to minimize the compile time cost would be to > move the Spirit.Qi based parser out to a .cpp and just build and > external lib. I'll try to make that happen locally and see how far > that goes, and I'll update everyone on what that's going to look like > for 0.9 soon as I'm done. > > Comments, feedback, violent reactions, etc. would be most appreciated. > Sounds like a good start. I'm not sure if you've been following or went to any of the MSM stuff this year at BoostCon, but that's a pretty sweet implementation if you need a state machine in the course of making cpp-netlib. Erik ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. |
From: Dean M. B. <mik...@gm...> - 2010-12-03 15:26:27
|
On Fri, Dec 3, 2010 at 11:17 PM, Nelson, Erik - 2 <eri...@ba...> wrote: >> Dean Michael Berris wrote on Thursday, December 02, 2010 11:35 PM >> I think the easiest way to minimize the compile time cost would be to >> move the Spirit.Qi based parser out to a .cpp and just build and >> external lib. I'll try to make that happen locally and see how far >> that goes, and I'll update everyone on what that's going to look like >> for 0.9 soon as I'm done. >> >> Comments, feedback, violent reactions, etc. would be most appreciated. >> > > > Sounds like a good start. > Thanks Erik. :) > I'm not sure if you've been following or went to any of the MSM stuff > this year at BoostCon, but that's a pretty sweet implementation if you > need a state machine in the course of making cpp-netlib. > Yes, I did -- and I was there! :D Unfortunately that's yet another hammer I need to learn to use. The implementation right now works with a hand-rolled incremental parser -- it's going to be interesting to see how I (or someone else) can port that to use Boost.MSM. The EUML stuff is cool and I'd really like to give that a spin. But, I don't have the time to much with that part of the implementation yet. Maybe later on I'll get more familiar with it and start moving the implementations to use Boost.MSM later on. -- Dean Michael Berris deanberris.com |