Language:
switch to room list switch to menu My folders
Go to page: First ... 49 50 51 52 [53] 54 55 56 57 ... Last
[#] Sat Mar 06 2010 12:24:12 EST from davew @ Uncensored

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

Hehe. Glad you found that. The new context branch also uses SIG_USR1 to interrupt the select when the list of fd's changes (new clients and current ones going idle).

 

Fri Mar 05 2010 09:30:49 EST from dothebart @ Uncensored

being fed up with

handle SIG_HUP nostop

typing on each citadel debugging action, I found out about ~/.gdbinit:

http://tinderbox.dev.gentoo.org/misc/dot.gdbinit

one probably should use that and add it there.



 



[#] Sun Mar 07 2010 05:05:15 EST from dothebart @ Uncensored

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

Heres my modified version.

it adds two macros special for libcitadel:

pstr -> dump the contents of a StrBuf*

dstr -> dump the contents of a StrBfu* to /tmp/[name]

...the signals.

Sa Mär 06 2010 12:24:12 EST von davew @ Uncensored

Hehe. Glad you found that. The new context branch also uses SIG_USR1 to interrupt the select when the list of fd's changes (new clients and current ones going idle).

 

Fri Mar 05 2010 09:30:49 EST from dothebart @ Uncensored

being fed up with

handle SIG_HUP nostop

typing on each citadel debugging action, I found out about ~/.gdbinit:

http://tinderbox.dev.gentoo.org/misc/dot.gdbinit

one probably should use that and add it there.



 



 



.gdbinit (application/octet-stream, 29574 bytes) [ View | Download ]
[#] Sun Mar 07 2010 21:24:21 EST from Ford II @ Uncensored

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

Beef of the week: Let's say you have 7 ArrayLists in java. They're parallel arrays, and by that I mean arraylist 1 has first name, arraylist2<string> has last name, arraylist3<string> has stree address and so on.
you want to sort these 7 lists.
Well collectible.sort() you say.
except that the comparable that you implement only let's you overload compare, not swap() which must be there but is not exposed.
Hunting around it seems everybody has this problem, and java is flaws, because they apparently though it a better idea to maintain pretty object orientedidity than to make a fucking useful sortable class.
Apparently the 'right' way to do it is to turn your arrays into 1 array of a class with all that stuff in it, and sort the array of combinedclass and then demux it out again when you're done.
Of course you're going to say "but all that information should have been in a class in the first place."
Maybe so, but the problem at hand is you need to sort 7 parallel arraylists, and you can't.
Because they were too stuffy to implement a class where you could override the swap functionality.

[#] Mon Mar 08 2010 05:33:25 EST from fleeb @ Uncensored

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

Java is not a language with which you may apply Generic Programming principles.  It's an object-oriented language instead.



[#] Mon Mar 08 2010 22:10:38 EST from Peter Pulse @ Uncensored

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

I'm not a big defender of Java.. but C++ didn't even have a String class much less any collection classes for the first 20 years of its existence, and therefore pretty much sucked. I have my complaints but Java looks pretty good in comparison.
Anyway, I suppose you want to keep track of what objects they are swapping to sort the array, so that you can sort all the other arrays at the same time???
What I would do is dust off my old programming books and find the examples of different array sort algorithms, and write the 20 or whatever lines of code to sort all the arrays at the same time. The way you are explaining this problem, it seems a bit unfair to expect the author of the java sort shit to anticipate this kind of problem. But how about you do it this way:
Make another array which contains the key values and offsets. Sort that.
Now take the results and use them to shuffle around all your other arrays.

[#] Tue Mar 09 2010 08:37:19 EST from LoanShark @ Uncensored

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

Mar 8 2010 5:33am from fleeb @uncnsrd
Java is not a language with which you may apply Generic Programming
principles.  It's an object-oriented language instead.


Untrue. It works. Arguably better than for C++ - in C++ the compiler slows down horribly when you start to use templating, because you have to #include the entire universe.

The example cited by Ford is not good programming practice in any language that has support for more than the most rudimentary data structures.

[#] Tue Mar 09 2010 08:48:50 EST from LoanShark @ Uncensored

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


Further comments:

C++ templating really sucks. A better approach is usually to use closures, if the performance is acceptable. (Java will eventually inline your closures for you if they become enough of a problem.)

Java is certainly not the right tool for every job, but it's the right tool for 90% of typical business objects/web user interfaces - all that boring shit that we deal with day in and day out. It can be a non-starter solution for certain memory-intensive workloads, however, because of that pesky all-objects-on-the-heap problem.

One of the motivators for Ford's (badly written) problem could be avoiding that all-objects-on-the-heap problem, but that is usually a horrible example of premature optimization. Even Ford's (badly written) problem has a solution, however: and that is to intercept the Collection method calls and use that to provide an equivalent of overriding swap().

[#] Tue Mar 09 2010 09:17:24 EST from fleeb @ Uncensored

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


I did not say Java did not work.

I said Java is not a language with which you may apply Generic Programming principles.

Ford appeared to be taking an approach that involved thinking through the problem in a Generic Programming fashion. That would work effectively in languages that support that kind of approach, but I don't think Java works that way. Java feels closer to Smalltalk in how it relies upon an object oriented solution to solving problems.

As for C++'s templating and such... I didn't intend to touch off a C++-is-better-than-Java thing. I'm comfortable with templating, but I can appreciate how others would not be. Yeah, I use C++ for most of my problems (to solve them, that is), and I'm not a particular fan of Java (I would prefer Smalltalk), but whatever does the job is fine by me.

[#] Tue Mar 09 2010 09:27:35 EST from fleeb @ Uncensored

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


Just to underscore what I mean by Generic Programming:

http://en.wikipedia.org/wiki/Generic_programming

And, yeah, there's mention of 'Generic in Java' in the article, but overall, I don't think Java is designed with this style of programming in mind.

[#] Tue Mar 09 2010 14:04:55 EST from Peter Pulse @ Uncensored

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

It was inevitable that the C++ comparison was going to come up. As far as the Generic Programming thing.. now that I have read the article.. well.. writing code such that it is able to be re-used with different data types and in different applications without alteration is nothing particularly novel or new. Languages which enforce type safety while you do it are somewhat novel. The pretentious name is new. Any C programmer who has implemented a few linked lists in their code, which is to say, EVERY C programmer, eventually either acquires or sits down and writes a generic linked list that they can use in all their projects. I did so 23 years ago. It is just good programming and every decent programmer will drift in that direction without being given fancy names for it simply because it is easier, saves time and makes sense.
But also sometimes it is easier to just bash out an application specific gak and not worry about all this shit. Ritchie grant me the serenity to accept the code I cannot change, the courage to change the code I should, and the wisdom to know the difference.

[#] Tue Mar 09 2010 15:08:49 EST from fleeb @ Uncensored

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


http://www.cs.rpi.edu/~musser/gp/index.html

The 'pretentious name' has been around a long time.

And at this point, I guess I should just zForget this room since, apparently, I can't even make a relatively innocuous statement without the insinuation that I'm a snob.

[#] Tue Mar 09 2010 15:35:39 EST from Peter Pulse @ Uncensored

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

If you want to be offended, which apparently you do, it is your right. You have historically trashed everything other than C++, and you wonder why you appear to be a C++ snob. The assertion you are making (that generic programming is not possible in Java or that Java is not conducive to generic programming) is not even true. Fords problem had to do with the choices made by the person who implemented the collection classes in not including some functionality that he wants.

[#] Tue Mar 09 2010 16:56:51 EST from LoanShark @ Uncensored

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

I said Java is not a language with which you may apply Generic
Programming principles.

Yeah, and I said you're wrong. ;) It does apply Generic Programming principles (as I understand them); heck, there is this little language feature called Generics that provides the parameterized types that seem to me to be the defining feature of that concept... but if we're gonna get into a flamewar (which I welcome ;) perhaps we should define our terms first.

[#] Tue Mar 09 2010 17:07:32 EST from LoanShark @ Uncensored

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

Just to underscore what I mean by Generic Programming:


All right, all right. You got there before I did. In another forum I frequent, I would be guilty of "jimskiing". Here, perhaps I'm just guilty of LoanSharking.


Java has parameterized types and as such provides a reasonable level of support for generic programming. That was the point. Now, it doesn't arrive there by the same route as C++ at all... but at the language level, they both provide a similar level of syntactic sugar, minus things like operator overloading, which by the way, is not universally agreed to be a Good Thing.


Java is inherently more runtime bound than C++, and making use of Java's template/closure idiom makes it more so.. This is both good and bad, but in terms of programmer productivity for working with generics, I see the two languages at parity, except for garbage collection issues. Java could benefit from a better closure syntax, but it already has a poor man's version which is reasonably good.

The LISP programmers out there would be laughing at this whole discussion if they heard it. They'd be telling us how lambda expressions (closures by another name) accomplish the same thing and are more powerful. And they'd be correct.

[#] Wed Mar 10 2010 14:36:44 EST from Spell Binder @ Uncensored

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

I've been reading "Real World Haskell" published by O'Reily and Associates to get a better understanding of functional and generic programming, and from what I've seen so far, Haskell's type system seems much more elegant than either C++'s template system or Java's generics. This, is, of course, just my opinion, and, to be honest, I think what makes Haskell code look much cleaner to me is more due to type inferencing than anything.
Haskell Binder

[#] Wed Mar 10 2010 16:24:36 EST from LoanShark @ Uncensored

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


Haskell syntax is obviously powerful. I haven't spent too much time trying to get my head around it, but what I've seen so far sort of makes me wig out. It seems like it's erasing all the usual redundancy that is present in a lot of languages: like type declarations and even a lot of the block structure. It's interesting that functions can be written as sort of sparse switch statements that define some of the expected outputs (potentially leaving part of the function's domain unspecified and leaving it up to the compiler to decide on an actual decision tree to implement the function.)

The part that kinda makes me wig out is that SO MUCH of the redundancy is removed, that I'm unsure how to interpret what's left, by example.

Also, monads are kind of disfortunate.

[#] Wed Mar 10 2010 17:00:38 EST from LoanShark @ Uncensored

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

Java Type Inference Is Broken: Can We Fix It?

http://www.cs.rice.edu/~dlsmith/java-type-system-oopsla08.pdf

Interesting discussion of the finer points of Java's parameterized type system. Certain unimplemented corner cases are identified.

[#] Wed Mar 10 2010 18:03:56 EST from Peter Pulse @ Uncensored

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

A friend of mine is really into Haskell, he developed a whole appserver system in it. One of these days I'll get him to walk me through it.

[#] Wed Mar 10 2010 22:46:01 EST from Ford II @ Uncensored

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

Anyway, I suppose you want to keep track of what objects they are
swapping to sort the array, so that you can sort all the other arrays

at the same time??? What I would do is dust off my old programming

Yes, zactly. as for dusting off the books, yes, that's the right way to solve the problem, but it kinda defeats the whole purpose of having all that stuff already in the existing libraries. The standard java api is pretty well thought out (except for date of course, but they evetually got that right) but they seemed to have skipped this one useful thing.
Your suggestion about the key offset arrays is certainly simpler, but you still have to copy and demux afterwards.
It just seems like a glaring misstep to me.

[#] Wed Mar 10 2010 22:58:50 EST from Ford II @ Uncensored

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

Hmmm... well here's my two cents.
templates in C++ are a hack that enables those overcomplicated macros everybody's been writing all these years to be compiler aware and therefore type checked. I was never a big fan, it always seemed pretty obvious to me that it's just a code generator, since everything has to be known at compile time, so really they just rewrote the macro preprocessor into the compilter.
I read the abstract of that article, it made me laugh: even though java authors got input from the java community process, they nevertheless included a novel mechanism....

Java in its heavy-run-time nature can afford to implement generics not as a precompiler, but it just seemed like they were doing taht to keep up with C++.
I'm not sure I see how generic programming is at all OO. They just wanted tokeep up with the joneses.


Go to page: First ... 49 50 51 52 [53] 54 55 56 57 ... Last