LFUDA changes #47
|
@ -66,11 +66,14 @@ func (l *LFUDAStore) Get(hash string) (stream.Blob, error) {
|
||||||
![]() the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM. I since worked with the developer of the library to address this so i believe we can go back to using a bool the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM.
I since worked with the developer of the library to address this so i believe we can go back to using a bool
![]() seems weird to do this. why not an actual seems weird to do this. why not an actual `bool`, or an empty struct?
![]() the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM. I since worked with the developer of the library to address this so i believe we can go back to using a bool the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM.
I since worked with the developer of the library to address this so i believe we can go back to using a bool
|
|||||||
|
|
||||||
// Put stores the blob. Following LFUDA rules it's not guaranteed that a SET will store the value!!!
|
// Put stores the blob. Following LFUDA rules it's not guaranteed that a SET will store the value!!!
|
||||||
func (l *LFUDAStore) Put(hash string, blob stream.Blob) error {
|
func (l *LFUDAStore) Put(hash string, blob stream.Blob) error {
|
||||||
err := l.store.Put(hash, blob)
|
|
||||||
![]() seems weird to do this. why not an actual seems weird to do this. why not an actual `bool`, or an empty struct?
![]() the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM. I since worked with the developer of the library to address this so i believe we can go back to using a bool the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM.
I since worked with the developer of the library to address this so i believe we can go back to using a bool
|
|||||||
if err != nil {
|
|
||||||
![]() seems weird to do this. why not an actual seems weird to do this. why not an actual `bool`, or an empty struct?
![]() the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM. I since worked with the developer of the library to address this so i believe we can go back to using a bool the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM.
I since worked with the developer of the library to address this so i believe we can go back to using a bool
|
|||||||
return err
|
|
||||||
![]() seems weird to do this. why not an actual seems weird to do this. why not an actual `bool`, or an empty struct?
![]() the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM. I since worked with the developer of the library to address this so i believe we can go back to using a bool the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM.
I since worked with the developer of the library to address this so i believe we can go back to using a bool
|
|||||||
}
|
|
||||||
![]() seems weird to do this. why not an actual seems weird to do this. why not an actual `bool`, or an empty struct?
![]() the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM. I since worked with the developer of the library to address this so i believe we can go back to using a bool the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM.
I since worked with the developer of the library to address this so i believe we can go back to using a bool
|
|||||||
l.lfuda.Set(hash, fakeTrue)
|
l.lfuda.Set(hash, fakeTrue)
|
||||||
|
has, _ := l.Has(hash)
|
||||||
![]() seems weird to do this. why not an actual seems weird to do this. why not an actual `bool`, or an empty struct?
![]() the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM. I since worked with the developer of the library to address this so i believe we can go back to using a bool the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM.
I since worked with the developer of the library to address this so i believe we can go back to using a bool
|
|||||||
|
if has {
|
||||||
![]() seems weird to do this. why not an actual seems weird to do this. why not an actual `bool`, or an empty struct?
![]() the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM. I since worked with the developer of the library to address this so i believe we can go back to using a bool the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM.
I since worked with the developer of the library to address this so i believe we can go back to using a bool
|
|||||||
|
err := l.store.Put(hash, blob)
|
||||||
![]() seems weird to do this. why not an actual seems weird to do this. why not an actual `bool`, or an empty struct?
![]() the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM. I since worked with the developer of the library to address this so i believe we can go back to using a bool the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM.
I since worked with the developer of the library to address this so i believe we can go back to using a bool
|
|||||||
|
if err != nil {
|
||||||
![]() seems weird to do this. why not an actual seems weird to do this. why not an actual `bool`, or an empty struct?
![]() the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM. I since worked with the developer of the library to address this so i believe we can go back to using a bool the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM.
I since worked with the developer of the library to address this so i believe we can go back to using a bool
|
|||||||
|
return err
|
||||||
![]() seems weird to do this. why not an actual seems weird to do this. why not an actual `bool`, or an empty struct?
![]() the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM. I since worked with the developer of the library to address this so i believe we can go back to using a bool the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM.
I since worked with the developer of the library to address this so i believe we can go back to using a bool
|
|||||||
|
}
|
||||||
![]() seems weird to do this. why not an actual seems weird to do this. why not an actual `bool`, or an empty struct?
![]() the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM. I since worked with the developer of the library to address this so i believe we can go back to using a bool the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM.
I since worked with the developer of the library to address this so i believe we can go back to using a bool
|
|||||||
|
}
|
||||||
![]() seems weird to do this. why not an actual seems weird to do this. why not an actual `bool`, or an empty struct?
![]() the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM. I since worked with the developer of the library to address this so i believe we can go back to using a bool the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM.
I since worked with the developer of the library to address this so i believe we can go back to using a bool
|
|||||||
return nil
|
return nil
|
||||||
}
|
}
|
||||||
|
|
||||||
![]() why are Put and PutSD implemented differently? why are Put and PutSD implemented differently?
|
|||||||
|
|
||||||
![]() seems weird to do this. why not an actual seems weird to do this. why not an actual `bool`, or an empty struct?
![]() the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM. I since worked with the developer of the library to address this so i believe we can go back to using a bool the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM.
I since worked with the developer of the library to address this so i believe we can go back to using a bool
![]() seems weird to do this. why not an actual seems weird to do this. why not an actual `bool`, or an empty struct?
![]() the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM. I since worked with the developer of the library to address this so i believe we can go back to using a bool the reason I did this was because the library wasn't treating a bool as a 1byte type and it would waste a lot of RAM.
I since worked with the developer of the library to address this so i believe we can go back to using a bool
|
seems weird to do this. why not an actual
bool
, or an empty struct?