If table["�"] is last key , I forget � key name, but I want get this table key's val (like seq[^1])
I see source iterator, t.data[^1] can get it, But t.data is private
let L = len(t)
for h in 0 .. high(t.data):
if isFilled(t.data[h].hcode):
yield (t.data[h].key, t.data[h].val)
Add this funtion maybe can use idx get key value
template getKeyVal(t, idx): untyped =
let len = len(t)
if idx >= 0 and idx < len:
result = (t.data[h].key, t.data[h].val)
else: ()
Its not that simple. Capacity != Count in underlying table. Still, IMO this should be in tables.nim. Its not ideal but better than nothing.
proc raiseIndexError(ndx, max : int) =
raise newException(IndexError, "index " & $ndx & " not in 0.." & $(max-1))
proc keyAt*[A,B](t: OrderedTable[A, B], at: int) : A =
if at<0 or at>=t.counter:
raiseIndexError(at,t.counter)
var ndx = 0
forAllOrderedPairs:
if at == ndx:
result = t.data[h].key
break
inc(ndx)
proc valueAt*[A,B](t: OrderedTable[A, B], at : int) : B =
if at<0 or at>=t.counter:
raiseIndexError(at,t.counter)
if at<0 or at>=t.counter:
raise newException(IndexError, $at)
var ndx = 0
forAllOrderedPairs:
if at == ndx:
result = t.data[h].val
break
inc(ndx)
Sorry, didn't notice your reply
A small pixel game engine can't print cjk unicode font, I want write function support unicode, Some font lib are not small, So want to read the png to display the unicode font in pixel game.
If nim official comes with mini font and image library in the future ,that would be great! :)
I think there is an argument to be made for "something super basic in std/ that could maybe be a B-tree" and something else with a lot of knobs/levers when people know they want a hash table and want to be able to tune it. In fact, that might even be what @Araq has a draft of.
I am also fine with lptabz or something like it moving into std/ and in general a "big std/". There are many other features of lptabz that might be popular. While I understand that Nim-core is overwhelmed and there are over a half dozen package managers, brand new users are probably better served not having to learn anything beyond "import std/xyz" and that aspect of UX also matters.
People praise Go's stdlib and used to praise Python's (and now instead struggle with requirements.txt and Docker and ...). Linus long ago lost track of all things going on in the Linux kernel and instead has a "trusted lieutenant" model. At least since C++ STL & Java, I have thought "stdlibs sell prog.langs". Maybe things have shifted to "package managers sell prog.langs" { and that shift started with CTAN/CPAN (around the same time as STL/Java)! Hah! -- In human affairs, "all of the above" is often overlooked, yet more accurate than any one thing }.
Anyway, there are no absolute answers to any of this -- delegation saves so much/allows scaling but trust sure is tricky! It's all an infectious cluster of Wicked Problems sometimes called "coordination games" which may be simply insoluble. In terms of your expectations, I think it goes against current thinking of instead trimming the stdlib as much as possible.
Also, Angluca, I'm making a guess here, please bear with me. I suspect you're not native English speaker, so just a suggestion: Perhaps you will be more comfortable to describe your problem more freely and in more detail in your native language and then use some service like deepl.com to translate it to English?