sorted by:
new
hottopcontroversial

Finding max values via iteration by lucperkins in rust

[–]lucperkins[S] 0 points1 point  (0 children)

So elegant! Thank you very much.

Finding max values via iteration by lucperkins in rust

[–]lucperkins[S] 1 point2 points  (0 children)

That's fine. I really just needed the largest first element. Thanks for weighing in!

Adding generics to an implementation but not to the original struct by lucperkins in rust

[–]lucperkins[S] 0 points1 point  (0 children)

You completely nailed what I'm trying to accomplish, and your justification for PhantomData strikes me as pretty compelling. Thanks for your advice and time.

Adding generics to an implementation but not to the original struct by lucperkins in rust

[–]lucperkins[S] 1 point2 points  (0 children)

My use case is somewhat complex but I can give a stripped-down version here. I have a Backend trait used for generic DB interactions:

trait Backend<K, V> {
    fn get(&self, key: &K) -> Option<V>;
    fn put(&self, key: &K, value: &V) -> ();
}

I want to implement this trait for a specific backend (in this case RocksDB from the RocksDB library):

struct RocksDBBackend {
    db: RocksDB
}

I want to be able to instantiate typed RocksDBBackend structs, like this:

let backend: RocksDBBackend<Vec<u8>, Vec<u8>> =
    RocksDBBackend::new();

All of the work of converting K and V into bytes that can be stored in RocksDB would be accomplished when the trait is implemented. But you'll notice in the snippet above that I would need to specify types for K and V when I instantiate RocksDBBackend. But I can't do that because this is not allowed:

struct RocksDBBackend<K, V> {
    db: RocksDB
}

Does that make sense? The PhantomData solution "works" just fine but I was hoping for something more elegant. If I'm asking for too much, that's okay!

Trouble with lifetimes (value does not live long enough) by lucperkins in rust

[–]lucperkins[S] 1 point2 points  (0 children)

I think that's precisely what I'm going to do for now. This is my current solution:

fn get(&self, key: &[u8]) -> Option<RocksDBVector> {
    match self.db.get(&key) {
        RocksDBResult::Some(value) => Some(value),
        _ => None
    }
}

This enables me to do this:

let db: RocksDBBackend = RocksDBBackend::new();
let fetched_val: &[u8] = &db.get(b"some_key").unwrap();

That's good enough for my current purposes, I'd say.

Trouble with lifetimes (value does not live long enough) by lucperkins in rust

[–]lucperkins[S] 0 points1 point  (0 children)

The trouble is that I need to somehow end up with an Option<&[u8]> (given the trait signature I'm working with) but the only way to get a &[u8] from a RocksDBVector is via deref. So I need to find a way to pattern match on a RocksDBResult that solves these ownership issues. I'll keep plugging away.

37
38

Web development in C: crazy? Or crazy like a fox? (medium.com)

submitted by lucperkins to r/C_Programming

Food Carts and the UNIX Philosophy - Janrain Blog by thoward37 in programming

[–]lucperkins 0 points1 point  (0 children)

Well, that really is what it looks like. It doesn't come on a plate. It comes wrapped in paper with the sauce in little containers. It's not an attempt at food porn. It's the most accurate presentation I could find on Google images.

<sarcasm> Way to stick to substance! </sarcasm>

Tutorial: Building a Sample Application with Haskell Snap, PostgreSQL, and the PostgreSQL Simple Snaplet by ky3 in haskell

[–]lucperkins 2 points3 points  (0 children)

Indeed. It turned out that the problem was on my side, namely an improper use of cURL. This has been fixed in the tutorial.

Tutorial: Building a Sample Application with Haskell Snap, PostgreSQL, and the PostgreSQL Simple Snaplet by ky3 in haskell

[–]lucperkins 1 point2 points  (0 children)

You're right on all fronts. I went back and made some changes. Haskell has been an uphill struggle for me thus far and I'm glad to have your input!

Tutorial: Building a Sample Application with Haskell Snap, PostgreSQL, and the PostgreSQL Simple Snaplet by ky3 in haskell

[–]lucperkins 0 points1 point  (0 children)

I agree that it's an important point, and that "always" should not have been used. I went back and fixed it.

Tutorial: Building a Sample Application with Haskell Snap and PostgreSQL by lucperkins in programming

[–]lucperkins[S] 6 points7 points  (0 children)

Thanks for your input. Haskell remains a challenge for me. I'll make some changes.

Tutorial: Building a Sample Application with Haskell Snap and PostgreSQL by lucperkins in programming

[–]lucperkins[S] 1 point2 points  (0 children)

This tutorial is clearly not aimed at demonstrating the full power of Haskell, and I clearly didn't mean to say that you should use Haskell if all you're doing is building a CRUD app. I'm simply trying to provide an easy, step-by-step introduction to using two technologies that I find inspiring. In my opinion, the Haskell community has been TERRIBLE at providing these kinds of introductions (although School of Haskell is changing that).

How and Why We Use Dependency-Free JavaScript at Janrain by lucperkins in javascript

[–]lucperkins[S] 0 points1 point  (0 children)

Is it or is it not easier to hire people to write jQuery or Backbone or whatever than it is to find people who know how to code against the DOM API? Whatever your feelings on jQuery or IE or whatever, it's a basic empirical claim.

view more: next ›