Language:
switch to room list switch to menu My folders
Go to page: First ... 53 54 55 56 [57] 58 59 60 61 ... Last
[#] Wed Apr 21 2010 16:42:49 EDT from LoanShark @ Uncensored

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

Heh heh heh...

"Binding
Actually, the name .bind. comes from Haskell. Scala.s term for this
operation is .flatMap. because the operation may be viewed as a
combination of the map and flatten methods. Of all of the techniques
discussed so far, this one probably has the richest theoretical
implications. Coming straight from the menacing jungles of category
theory and the perplexing wasteland of monads, flatMap is both
intriguing and apparently useless (at first glance anyway).

[#] Wed Apr 21 2010 22:36:39 EDT from Ford II @ Uncensored

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

Which would make the code much more flexible if we ever had to look
for a different error condition, but, this code hasn't changed in years


But more importantly you are an older and wise programmer and you know better than to overengineer a piece of software to handle conditions you know it will never need to.
If only there was a stick I could hit people with that would teach them that.

[#] Wed Apr 21 2010 22:42:43 EDT from Ford II @ Uncensored

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

Good talk on how to code for multicore / parallelism. (GLS, of course,

ends up asserting that LISP/Scheme hackers were right all along ;)

Well, the lisp guys have an advantage because if you use enough parenthesis in one expression you can obviously break it down into litt le pieces that can be run in parallel because they would run independantly if run sequential anyway.
But that means you have to design the program/expression in a parallelizable way in the first place.
And you don't need LISP to do that.
Seems to me you could markup C (not saying this is the best idea, but you could) to denote parellelizable sections that aren't dependant on each other and let the compiler have at.

As a matter of fact, isn't that how the itanium works? I remember I love the itanium design, but it's been so long since I've been on that bandwagon I forget why I love it. :-)

[#] Thu Apr 22 2010 04:12:31 EDT from dothebart @ Uncensored

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

 

Mi Apr 21 2010 22:36:39 EDT von Ford II @ Uncensored
Which would make the code much more flexible if we ever had to look
for a different error condition, but, this code hasn't changed in years


But more importantly you are an older and wise programmer and you know better than to overengineer a piece of software to handle conditions you know it will never need to.
If only there was a stick I could hit people with that would teach them that.

there is. its called clue stick. available at http://www.electromagnetic.net/store/cbx.html be shure also to check out the NAIL (Neural Access Interface Layer) attachment.



[#] Thu Apr 22 2010 11:23:28 EDT from LoanShark @ Uncensored

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

Well, the lisp guys have an advantage because if you use enough
parenthesis in one expression you can obviously break it down into litt

le pieces that can be run in parallel because they would run
independantly if run sequential anyway.

There's definitely an advantage in more flexible, terse syntax but it doesn't come from parentheses, it originates mainly from first-class functions, and to a lesser degree, first-class macros.


I hate the parentheses, the flat namespace, and the image-based runtime environment of Lisp. But Scala is starting to look sensible.

[#] Thu Apr 22 2010 11:26:32 EDT from LoanShark @ Uncensored

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


For example, Java is not going to be able to compete with this for 5-10 years, but Scala has this coming Real Soon Now:

http://groups.google.com/group/scala-incubator/browse_thread/thread/973bed8fd74f62d8

[#] Thu Apr 22 2010 12:52:41 EDT from LoanShark @ Uncensored

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


How to have your closure cake and eat it too:

http://lamp.epfl.ch/~dragos/files/talk-hofs.pdf

[#] Fri Apr 23 2010 13:37:19 EDT from LoanShark @ Uncensored

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


Did some microbenchmarking here. scalac's @inline works well. (The target method must be declared final and the concrete implementation must be known at compile time, in order for it all to work.) Works reasonable well in Scala 2.7.7: write a couple different implementation of "summing a list of integers", one with a while loop, and one with a hand-coded "reduce" function, plus a few other versions. The generated bytecode is fully inlined and only uses primitive datatypes. However the bytecode is about twice as long with "reduce" as it is for the "while" loop. Performance doesn't suffer too much: 2000ms for "reduce" vs 1875ms for "while". By comparison, some un-inlined versions can be 10x slower due to autoboxing and invokevirtual. Situation is even better under 2.8.0 nightly build: the inlined "reduce" version seems essentially equivalent to the "while".

So now we have C++ templates on a JVM, except with reasonable modularization and compile time performance (none of this "stick your entire program in a header file"!). :->


Next up: operator overloading and implicit conversions.

[#] Fri Apr 23 2010 17:19:57 EDT from LoanShark @ Uncensored

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

... or not. Operator overloading exists in Scala, but I don't see a way
to apply it against parameterized types without extra boilerplate.

Scala generics have many advantages over Java's, such as the inclusion
of an equivalent to C's "typedef" - which should eliminate the "viral
generics" problem in applications that attempt to make nontrivial use of
generics.

There's also type specialization: some syntactic sugar that
autogenerates specialized versions of generic interfaces in order to
avoid autoboxing. E.g., the compiler automatically generates an
ArrayList[Int] that stores an array of primitives instead of their boxed
versions. Should yield large memory savings and significant runtime
speedup, perhaps around 2-10x on some simple micro benchmarks.)

http://www.scala-lang.org/sites/default/files/sids/dragos/Mon,%202009-11-16,%2017:34/sid-spec.pdf

One more way in which Scala's
combination of features enable deploying
highly factored, highly modular code on the JVM without the performance
penalty of semantically equivalent code written directly in Java.

[#] Sat Apr 24 2010 16:23:13 EDT from dothebart @ Uncensored

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

after having fiddled with pylucene (welcome to the dependency hell..) while setting up reviewboard stumbled over an alternative:

http://xapian.org/features

well, its c++, so for citadel it would increase the build dependency list... but I think its something _real_ different than pulling a java interpreter and jni bullshit

 



[#] Sat Apr 24 2010 19:37:02 EDT from LoanShark @ Uncensored

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


C++ is dead. (Print Is Dead, too.)

Just for Spell: some level of Monad support in Scala? I don't pretend to understand this, just passing it on.

http://stackoverflow.com/questions/1163393/best-scala-imitation-of-groovys-safe-dereference-operator

(Scala doesn't seem to need monads so badly, since it's not a pure functional language.)

[#] Mon Apr 26 2010 12:55:35 EDT from Spell Binder @ Uncensored

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

I'm not familiar with Scala, but I can still see the advantage of monads even in imperative or object-oriented languages.

From what I can gather reading the article, they're looking for a way to model Haskell's Maybe monad; i.e. a chain of computations that should "abort" if any computation in the chain returns Nothing. In an imperative language, you'd have to do this with a series of if-then-else statements. In an object oriented language, this could be done with a special method-invokation operator, which is, I believe, what they're referring to as that "safe dereference operator."

The parallels are there, though. The suggested "?" or "?." operators are versions of the monadic bind operation, but specialized for Scala's Option type--the equivalent of Haskell's Maybe type. The "toOption" method mentioned near the end is the monadic injector for getting a non-monadic value into a monad, Scala's Option, in this case.

It's interesting to me because I remember learning about method-chaining in Smalltalk. I think it was called "cascading," whereby you could chain the result of one method call to become the target object for the next method.
I don't think I encountered this situation in my code, but it did leave me scratching my head thinking, "What would happen if one of these methods returned an unexpected object?" I knew the answer was that polymorphism would kick in, and if no method could be found in the class hierarchy, it would eventually bubble up to the Object class (which is the end-all be-all superclass in Smalltalk; it's even a subclass of itself!) where it would be handled and generate an "unknown method" exception.

It does make me wonder what a monad implementation might look like in Java or C++.
Monad Binder

[#] Mon Apr 26 2010 18:06:49 EDT from IGnatius T Foobar @ Uncensored

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

after having fiddled with pylucene (welcome to the dependency hell..)
while setting up reviewboard stumbled over an alternative:

Isn't there a C version of Lucene?

[#] Mon Apr 26 2010 18:28:24 EDT from dothebart @ Uncensored

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

 

Mo Apr 26 2010 18:06:49 EDT von IGnatius T Foobar @ Uncensored
after having fiddled with pylucene (welcome to the dependency hell..)
while setting up reviewboard stumbled over an alternative:
Isn't there a C version of Lucene?

since its done in java, a wrapper at best. I guess pylucene is a wrapper around that wrapper.. yak.



[#] Tue Apr 27 2010 11:40:24 EDT from IGnatius T Foobar @ Uncensored

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

Actually no, CLucene is a port of Lucene, not a wrapper around it.

http://clucene.sourceforge.net/

[#] Tue Apr 27 2010 12:15:58 EDT from dothebart @ Uncensored

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

but its also written in c++ and uses cmake -> additional dependency

It seems as if the 'oldstable' thing is a little outdated, and one is encouraged to use a git version if one wants to be recent.

The stable version is available in debian.

A question would be how much the API from old stable and bleeding edge differ, or if its just the code bedind it.

But I think the java version also isn't snap-in-replaceable, since some debian guy told me that the lucene package would need a complete overhaul to be updated to latest stable...



[#] Tue Apr 27 2010 17:03:10 EDT from LoanShark @ Uncensored

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

are versions of the monadic bind operation, but specialized for Scala's

Option type--the equivalent of Haskell's Maybe type. The "toOption"

Ok, still don't understand monads. But I just opened the source for the Option type in Eclipse, and noticed that it implements many of the standard combinators: filter, fold etc as well as a getOrElse. So basically it's a collection that can only hold one thing, but it's not the same thing as the singleton List. Which all seems kind of pointless, but I suppose this sort of thing might be considered useful if you've been heavily drinking from the Category Theory punchbowl and/or you've done so much refactoring that your entire codebase has morphed into arity-2 map methods, then you can just write a whole program by chaining getOrElse invocations and other combinators. Which also seems like a silly exercise ;)

[#] Wed Apr 28 2010 10:27:18 EDT from Ford II @ Uncensored

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

I've come to appreciate that IE for all of its failings is a lot more strict about some of the things it does.
firefox will eat anything and make it do something, consequently there's lots and lots and lots of shitty html css and javascript out there that works because firefix is very lax about what it's doing.
I'm on the fence about the whole thing. It's nice to be able to be sloppy just to get it done, because to me, all web stuff is shit anyway, I have no desire to raise it to my high standards of other programming I do.
But on the other hand it's respectable that IE wants you to do the right thing, and if you can get it to work on IE it'll definetly work on firefox.
The problem is IE has exactly zero error reporting.
So when it doesn't work, the debugger toolbar pops up your javascript with the errant line and tells you exactly nothing about what's wrong with it.
Today I found out that if you create an element in a document that's part of frame 1 you can't add it to the document of frame2.
Of course you can in firefox, but not ie. But ie doesn't tell you what's wrong, it just gives you that little error box.
At one point I got it to say "invalid argument"
Really fucking helpful.



[#] Wed Apr 28 2010 10:30:29 EDT from Ford II @ Uncensored

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

For those following along at home, the goal is a rather uncommon one.
Two frames, top frame is a menubar that does dropdowns.
But of course the dropdowns wont overlap over the frame border, so I dreamt up this neat trick where I copy the css and the drop down menu element to the lower frame, then do lots of javascript to notice when you are mmouseovering the top frame menu bar and the bottom frame menu bar.
Had it working in FF on monday, been fighting with IE ever since.
I sorta got it to work in IE this morning so at least what's in FF works in IE now, but there's still a long way to go.

I hate doing shit like this, because it's kludgy by design and works practically by accident. Stuff like this is a nightmare to support. But I see no other way.
Iframes don't work because you can't know the size of the application you're loading into the lower frame.

[#] Wed Apr 28 2010 10:43:48 EDT from dothebart @ Uncensored

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

firefox is lax so it could cope with all the shit IE6 brought into existance.

for example ie6 will accept \'s as /'s in URLs without any doubt.



Go to page: First ... 53 54 55 56 [57] 58 59 60 61 ... Last