Language:
switch to room list switch to menu My folders
Go to page: First ... 42 43 44 45 [46] 47 48 49 50 ... Last
[#] Mon Dec 21 2009 20:14:41 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Mon Dec 21 2009 19:37:30 EST from Ford II @ Uncensored
Now you're just being negative.

I'm being neutral, the world is negative.

I need to remember this.



[#] Tue Dec 22 2009 06:55:44 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Fri Dec 18 2009 19:35:26 EST from IO ERROR @ Uncensored
On a totally different note: Ford, my nice Core i7 compiles all of Citadel in just under a second.

real 0m0.863s
user 0m3.116s
sys 0m0.888s

But configure still takes forever. Isn't there anything better than GNU autoconf yet?

Have you examined:

http://www.cmake.org/Wiki/CMake

I'm only just starting to look at it, but boost seems to be moving to it, so it has piqued my curiosity.



[#] Tue Dec 22 2009 09:55:03 EST from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

one of our depedencies, libical, also has a cmake build.

Tried it once, and got stuck since I started out on a to complicated thing.

Another issue: you definitely need cmake on your system to compile, while autofoo just needs shell.

like the xmkmf thing...

but, better than scons, which you need python for (welcome to the dependency hell)

While having also a cmake build available for development and equipped build environment would be nice, switching to it would definitely work against the easy install approach, which has to have an entry level as low as possible.



[#] Tue Dec 22 2009 16:09:18 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I suspect you could probably have some kind of makefile that just builds the cmake program without having to use autoconf.  I have this suspicion because boost wants to move to this tool, and they currently have ways of building bjam within your target environment as a bootstrapping mechanism.  I haven't checked to see whether or not this is true, though.

If this is true, you could build cmake as one of the steps towards building the citadel binaries.  Then, you wouldn't have to rely upon people having the borne shell, or autoconf, or whatever.



[#] Tue Dec 22 2009 16:45:26 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Did RogueWave have network socket tools with asynchronous i/o?  I
don't recall seeing that.

Yea, it had Tools++ for the main colelctions and stuff like that, and Net++ or something like that for all the socket stuff. I think it also had http classes which was pretty early on as those things go.

[#] Wed Dec 23 2009 05:59:03 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Ah, okay.  I never had to use Net++, just Tools++.

I'd like to think asio is better considered than Net++, but having never used it, I can't really say.



[#] Wed Dec 23 2009 08:06:22 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

As dothebart noted, speed is not always the most crucial thing. If source code is being distributed to a wide audience, it's more important to send out code with a build system that's going to work on the maximum number of environments without requiring everyone to set up new tools. If you're sending out binaries then you only need to worry about your own team and can go with whatever works best or fastest for them.

[#] Wed Dec 23 2009 12:38:33 EST from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Di Dez 22 2009 16:09:18 EST von fleeb @ Uncensored

I suspect you could probably have some kind of makefile that just builds the cmake program without having to use autoconf.  I have this suspicion because boost wants to move to this tool, and they currently have ways of building bjam within your target environment as a bootstrapping mechanism.  I haven't checked to see whether or not this is true, though.

If this is true, you could build cmake as one of the steps towards building the citadel binaries.  Then, you wouldn't have to rely upon people having the borne shell, or autoconf, or whatever.

fleeb, cmake is autofoo and automake and make integrated. It requires the cmake binary on the build host.

since the kde project uses it, it indeed is quiet mature.

If its just a build requirement for a package or portage, its not a big deal. But for running on a random system, it is.



[#] Wed Dec 23 2009 12:39:31 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I just saw eclipse do something crazy cool.
I told it to refactor and move a constant from one file to another. And it did, and it updated all the references as normal, but when I went to look at the constant's new location, I found it had even grabbed the comment just about it, and copied that too.
That's insane.

[#] Wed Dec 23 2009 20:10:35 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Wed Dec 23 2009 12:38:33 EST from dothebart @ Uncensored

 

Di Dez 22 2009 16:09:18 EST von fleeb @ Uncensored

I suspect you could probably have some kind of makefile that just builds the cmake program without having to use autoconf.  I have this suspicion because boost wants to move to this tool, and they currently have ways of building bjam within your target environment as a bootstrapping mechanism.  I haven't checked to see whether or not this is true, though.

If this is true, you could build cmake as one of the steps towards building the citadel binaries.  Then, you wouldn't have to rely upon people having the borne shell, or autoconf, or whatever.

fleeb, cmake is autofoo and automake and make integrated. It requires the cmake binary on the build host.

since the kde project uses it, it indeed is quiet mature.

If its just a build requirement for a package or portage, its not a big deal. But for running on a random system, it is.

One of us may be confused by the other.  I'm not sure.

Try this sometime... download the very latest version of boost, and type './bootstrap' on the command line within the boost root folder.  You'll notice (if it does what it does on Windows) that it builds an executable named 'bjam' in the root folder.  From there, you can execute the local bjam executable to build the rest of the boost system (which isn't much, really, since most of boost is just header files... but still...).  In this way, boost avoids depending up autoconf or any of that stuff... it only depends upon a C++ compiler.

Can you imagine how useful that could be for Citadel?  If you didn't even have to depend upon the shell, but could simply use a bootstrapping mechanism to build something like cmake, which could be used to build the rest of the Citadel executables, you'd be requiring fewer dependencies on the operating system.

But, it's kind of a big 'if'.  I know that boost isn't quite ready to move to cmake yet (they tried to use it for 1.41, but pulled it out at the last moment), so I suspect it isn't ready for that kind of power.



[#] Wed Dec 23 2009 20:11:51 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Wed Dec 23 2009 12:39:31 EST from Ford II @ Uncensored
I just saw eclipse do something crazy cool.
I told it to refactor and move a constant from one file to another. And it did, and it updated all the references as normal, but when I went to look at the constant's new location, I found it had even grabbed the comment just about it, and copied that too.
That's insane.

Wow... that's pretty powerful.  Nice IDE!



[#] Wed Dec 23 2009 21:41:02 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Dec 23 2009 12:39pm from Ford II @uncnsrd
I just saw eclipse do something crazy cool.
I told it to refactor and move a constant from one file to another.


I don't think my luck has been nearly as good with eclipse, telling it to move statics (consts or methods) around... maybe I should try again, maybe I'm just going about it wrong...

But I have been using "extract method" and "inline" and "change signature" and "introduce parameter" and "extract local variable" and "introduce parameter object" with some pretty good results...

we are using the eclipse-cs checkstyle plugin on all our projects as well, which has made us all into good little refactoring hitler youth members. sig heil.

[#] Thu Dec 24 2009 04:10:03 EST from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Mi Dez 23 2009 21:41:02 EST von LoanShark @ Uncensored
Dec 23 2009 12:39pm from Ford II @uncnsrd
I just saw eclipse do something crazy cool.
I told it to refactor and move a constant from one file to another.

I don't think my luck has been nearly as good with eclipse, telling it to move statics (consts or methods) around... maybe I should try again, maybe I'm just going about it wrong...

But I have been using "extract method" and "inline" and "change signature" and "introduce parameter" and "extract local variable" and "introduce parameter object" with some pretty good results...

we are using the eclipse-cs checkstyle plugin on all our projects as well, which has made us all into good little refactoring hitler youth members. sig heil.

Sieg Heil please! </spellingnazi>



[#] Thu Dec 24 2009 07:53:34 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


damnit, there I go, Godwins Law again...

[#] Thu Dec 24 2009 09:32:39 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

the one thing that's too =bad is that the jsp stuff is obviously an add on.
the refactoring of statics doesn't affect jsps, and jsps don't have nearly the fun quick fix stuff that the java class support does.
But I can tell it gets better with every version.
the javascript validator sucks horrendously however.

[#] Thu Dec 24 2009 17:21:53 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

After many months and much headbanging I finally got the frikkin openid thing to work.
What a pain in the ass. I don't see how this is supposed to be easier than writing your own secure authentication system.

[#] Wed Dec 30 2009 09:08:33 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Wow... just learned something new about vim that I hadn't known before.

If I'm working on a C++ class, I can tap ^p to complete a word... it will even give me a selection to choose from if the completion is ambiguous.

I haven't tested exactly how far it will go (e.g. whether it knows about the included files), but it definately knows about keywords within the same document.

[#] Wed Dec 30 2009 10:09:45 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


No, it doesn't handle the include files. However, if your code already refers to something in the include files, it's available to the completion routine.
So it's still pretty cool.

I wonder if the inclusion mechanism only attempts to complete what you already have in the current document, or if it can draw on the documents you might have in other buffers.

[#] Wed Dec 30 2009 11:48:05 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

you should see how nuts eclipse and the new .net studio do autocompletion.
Usually it's ctrl-space, but I'm sure vim wanted to be different.

In eclipse (the java editor) if you autocomplete a interface (a pure virtual class) it will fill out the entire list of functions you need to implement with method definitions, braces, and comments, in the formatting style that you've defined elsewhere in eclipse.
It will hunt not only anything you've specifically imported (included) in the current file, but it will hunt anything in dependant projects or libraries/jar files.

It's insane. And very addicting. It's the number 1 reason I prefer writing java to C++. I still prefer C++ as a language, but the actual writing is tons more fun in java.
The C++ stuff for eclipe has some of that, but it's nowhere near as flushed out.

[#] Wed Dec 30 2009 17:29:09 EST from IO ERROR @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

cmake is already in EPEL and in Fedora. So it could probably be used in the future with a small update to the prerequisites (or worst case by bundling it).

Go to page: First ... 42 43 44 45 [46] 47 48 49 50 ... Last