Everybody has an opinion on what features Nim needs. What we need is people who
can either (A) implement those features themselves, or (B) pay someone to do
it. ;)
loadExtensions worked. I've seen something about that function, but looked at
it and thought: Meh, can't be just that. I see now that example calls it too
before any gl* methods. Anyway, thanks for help ;] Cheers.
try adding the `loadExtensions` proc before calling any opengl function. Since
the example does work, you can incrementally transform the working example into
what you are trying to do, and see what you were missing, as soon as a change
breaks the code.
I've tried to copy
[this](https://www.opengl.org/wiki/Programming_OpenGL_in_Linux:_GLX_and_Xlib)
into nim, produced [this
code](http://forum.nim-lang.org///pastebin.com/kwzHi9b7) . It compiles without
problem but when I'm trying to execute it throws:
Traceback (most recent call l
> Some things, owing to their prevalence, in my opinion have to be part of
> standard library of language. For example, the string methodsfunctions
> toCharArray, getBytes, reverse are in many languages.
The problem is, when is enough... I can think of a dozen things i like to see
in Nim. But t
For me it's allowing to write code compact and looking intuitively, and having
many solutions to the same task, at programmer's choice. Something
characteristic for Ruby, but even more so for Nim.
Yet its Delphi's roots (which I think gave Nim much of its elegance).
> you can also put all of the helpers you coded into a package and publish it
> with Nimble
Some things, owing to their prevalence, in my opinion have to be part of
standard library of language. For example, the string methods\functions
**toCharArray**, **getBytes**, **reverse** are in many lan
Nim is great because it has this underdog spirit taking on all and everyone, it
is down to earth , not overly academic and most of it is fun.
The excitement feels similar to when I was changing from Fortran77 to Turbo
Pascal , if I recall that correctly. :P
They are probably the same type, so try just casting:
var wprc = cast[WNDPROC](GetWindowLongPtr(hCtl,GWL_WNDPROC))
Oh, good example. Thank you!
you can do the same with block labels:
block myBlock:
for i in 1..100:
someaction1(i)
if somecondition(i):
break myBlock
someaction2(i)
echo "No i matches the condition!"
So I would say, it doesn't make sense to add support fo
Given a MS Windows Control whose handle is hCtl, acquire its window proc:
var wprc:WNDPROC = GetWindowLongPtr(hCtl,GWL_WNDPROC) #statement 1
Inside an alternate window proc for a subclass of hCtl, final default execution
is:
CallWindowProc(wprc,handle,message,wp
Hi,
Would it make sense for Nim to borrow the following syntax from Python?
for i in 1..100:
someaction1(i)
if somecondition(i):
break
someaction2(i)
else:
echo "No i matches the condition!"
where the else clause is executed if and only if no
Fast / Low memory usage ( compared to competitors ) Compiles to a single binary
Relative clean syntax Macro support Hardware support Flexible
In other words, all of GoLang its features but better / more flexible / more
options / less limitations.
Since most posts here are basically about what people don't like (me included)
and questions about things that don't work, I would like to ask, what you like
the most about Nim. What is the reasons you believe in Nim. Or simply what part
of the language or the standard library do you think is th
@Araq I am sorry I stepped on your foot. Keep on with your work on this great
language, and thank you for very good community support. I mean it without any
sarcasm.
And you are completely right, Nim needs to focus on the things that are truly
important, and don't loose focus in the details.
I
16 matches
Mail list logo
