Re: Should we get rid of style insensitivity?
To me it seems clear that regular users generally prefer it the way it is. However I do not believe dom96 would make this post if he were not getting consistent feedback about this front potential adopters. I believe that signal should not be ignored. If the feature isn't being removed maybe it should be considered for some slight modification in terms of usage or documentation. Also I believe this is a microcosm of the larger challenge of user adoption and the boots-on-the ground recruitment process. One thought is that since I believe people want things that are familiar or popular and don't want things that are unfamiliar, if there were some way to make case insensitivity a cool new programming thing rather than just weird, that could change the feature into an asset for recruitment. Not that that would be easy to do. But if someone who was popular and had a reputation as a programming guru made a post about why case insensitivity is the new better way to go and that was well received, that would be a thing. In my opinion people will follow a trend subconsciously and then rationalize all the logical reasons they did it without knowing that they were actually just following a trend.
Re: Should we get rid of style insensitivity?
**I do not want a vote** , however, I think that "the decision makers" should read the thread and see if any arguments stand out to them or change their view and do what they feel best. That being said, I like @LibMan's third suggested option... * The compiler should generate a warning, but treat them as same identifier. That gives developers the freedom to focus on functional code but give the most anal retentive programmers the ability to quickly find and correct mismatched names.
Re: Should we get rid of style insensitivity?
> PS: Can we not edit our own posts? You can, don't you see a pencil button on your post?
Re: Should we get rid of style insensitivity?
I just read that dom prefers "I want a vote" or "I don't want a vote", but actually I don't really care about the style insensitivity either way. I think many people who dislike it do so largely because they think of it as "impure" for people to have to care about style sensitivity (e. g. you are a noob if you were to rely on case sensitivity, such as PHP). I myself do not see it that way simply because I actually think that the issue is between the human being, and the parser/lexer. So if it is not necessary, why should the parser care? I give you another example. Python mandates () for methods; in ruby the () are optional unless something is ambigous. I prefer the ruby way. Why? First, you can use the () anyway in ruby so you get the same as in python, except for in python they are MANDATORY. And I really hate mandatory syntax rules that restrict me in how I operate. It is for a similar reason I hate python's mandatory indent, since I can not copy/paste into the interactive python. This is why I think the style insensitivity is not really an issue save for people who think about "purity" of a language. But I don't really care either way enough to even want a vote, or not want a vote. There are so many other things to improve!
Re: Should we get rid of style insensitivity?
PMunch wrote: > And after having had to write some code in C and Ruby that doesn't have it > I'm > even more for it. I can not speak for C but in ruby you can make use of aliases. So: > def foo_bar end; alias foobar foo_bar This may be excessive to want to do so manually but you could batch-generate aliases to these methods on your own. It is not the same as having it on the same top-level support for the whole language (to compile it), but since the claim was that "ruby does not have style insensitivity", I feel that claim is ... weird because you could enforce it in different ways, probably even making use of rubocop's autocorrect option once you setup a style guide (either by also adding aliases as is perhaps, or using ruby code to do so).
Re: Should we get rid of style insensitivity?
Personally I do not care either way. To me the issue of case sensitivity or not has never been one that existed. For me personally the biggest problem is time :D - however had, past that point, I may wish to be able to use a "sub-dialect" of nim that is more light-weight in syntax. For example, things such as not having to use "var" to declare local variables and things like that. I love syntactic flexibilty but I understand that this is not on the roadmap towards 1.x.
Re: Should we get rid of style insensitivity?
PS: Can we not edit our own posts? I did want to edit it to clarify what I meant ... but I can not see an edit-button or so. I only see "reply", a heart icon, and the time ... quite strange forum here. Is it written in nim? :) I swear this also changes every some months... :P
Re: What'd I miss?
> For me, coding is a hobby For me too. My biggest issue altogether is lack of time. Ruby is my main language but I do not even get to write as much code a I once did, simply because I don't have the time. I still write code to solve things though, many trivial things that come up every day. >From that point of view, looking at different projects every some weeks really >means that time passes by quickly, and lots of changes happening.
Re: In the response always 4000 byte by AsyncHtpp request
Use `readAll`: [https://nim-lang.org/docs/asyncdispatch.html#readAll%2CFutureStream%5Bstring%5D](https://nim-lang.org/docs/asyncdispatch.html#readAll%2CFutureStream%5Bstring%5D)
Re: What'd I miss?
Yay! No more `nil` deference on strings. Awesome! @juancarlospaco Thanks! I'm happy about the pure functions.
Re: How to convert integer to pointer
Don't cast to refs, strings or sequences, those types are tracked by the garbage collector and the cast will not register those pointers with the garbage collector. Also I'm surprised you can have a typedesc field as in: type ListClass = ref object typ : typedesc pointR : ByteAddress Run
Re: How to convert integer to pointer
Note that casting to a `ref` instead of a `ptr` is usually not safe.
In the response always 4000 byte by AsyncHtpp request
Hi, please help, what do I do wrong?
proc getData(urlR: string): Future[(bool, string)] {.async.} =
var client = newAsyncHttpClient()
var r = await client.request(url = urlR)
result = await r.bodyStream.read()
var r = waitFor
getData("https://pde.cit.api.here.com/1/tiles.json?layers=PSTLCB_GEN,PSTLCB_GEN,PSTLCB_GEN,PSTLCB_GEN,PSTLCB_GEN,PSTLCB_GEN,PSTLCB_GEN,PSTLCB_GEN=12,12,12,12,12,12,12,12=6523,1907,6524,1907,6525,1907,6526,1907,6527,1907,6528,1907,6529,1907,6530,1907_id=NRQTf9fPQwBbKMe5uh1O_code=1hNS1cEpObup1p1AKfxSyw=1;)
echo r[0]
echo r[1].len
echo r[1]
Run
thanks
Re: How to convert integer to pointer
Thank you mratsim. I will use ByteAddress instead of int. Anyway, Can you
please guide me on this ?
type
ListClass = ref object
typ : typedesc
pointR : ByteAddress
var x = new ListClass
x.typ = string
x.pointR = cast[ByteAddress](addr("A sample string"))
var y : seq[ListClass]
y.add(x)
# Then later...
var z = cast[ref y[0].typ](y[0].pointR)
echo z[] # Here i want to print "A sample string"
Run
Re: How to convert integer to pointer
Ok, i 've got the partial answer. var s = cast[ref Sample](p)[] Run Now, one question arises. Is it possible to keep the type name and use it when needed ? I mean ; var abc = Sample var p = cast[int](addr(abc)) Run By this time, i know p is an int form of a pointer which pointing to a Sample object. I can keep p in a seq. Similarly, how can i store the type name "Sample" in order to use later ?
Re: How to convert integer to pointer
You can `cast[ptr T](yourInt)`, and to dereference: `yourPtr[]`. Instead of `int` I strongly suggest you to use `ByteAddress`. Here is an example of using pointer<->int conversion to align a pointer on 64-bit boundary. [Source](https://github.com/numforge/laser/blob/432e8f22ae63e798a9dcf49f2f2d407578d54c57/laser/private/memory.nim#L10-L21). import typetraits const LASER_MEM_ALIGN = 64 func align_raw_data*(T: typedesc, p: pointer): ptr UncheckedArray[T] = static: assert T.supportsCopyMem let address = cast[ByteAddress](p) let aligned_ptr = block: let remainder = address and (LASER_MEM_ALIGN - 1) # modulo LASER_MEM_ALIGN (power of 2) if remainder == 0: cast[ptr UncheckedArray[T]](address) else: let offset = LASER_MEM_ALIGN - remainder cast[ptr UncheckedArray[T]](address +% offset) # +% interpret the operands as unsigned return aligned_ptr Run
How to convert integer to pointer
Hi all, I have 2 questions. 1. How to convert an integer to pointer ? 2. How to dereference that pointer ? See this code sample type Sample = object of RootObj intVar : int strVar : string var abc = Sample var p = cast[int](addr(abc)) Run So here i have an integer "p" and i need to convert it to a pointer again and i also need to get the data "abc" from that pointer. Any help would be appreciated. Thanks.
Re: Should we get rid of style insensitivity?
Case typos are not a big issue. Compilers errors messages will points you in the right line. If you import C identifiers (or other languages) style insensitivity may introduce hard to find bugs. In some cases the compiler can silently replace a_thing by aThing . It's less common than typos, but it can takes lot of time to find because the program works without errors. I don't ask for removing insensitivity, maybe it has more benefits than annoyances, I don't know. Do what you want but for newcomers, or bad programmers like me, please add a warning, or recommend people to change the names from foreign languages files.
Re: Should we get rid of style insensitivity?
For me, this idea of voting is strange and even makes me uncomfortable. Does the creator of the language agree with this procedure? If this is not the case, we are following a wrong path here. Moreover, are we going to vote for each presumably controversial topic, for instance the syntactically significant indentation? If would be the logical next step, but I’m not sure it will do any good to the language which will quickly look like some of these committee languages with lot of compromises to please a majority of users. In fact, this is the first time I see such a fuss about case insensitivity. Before C, most languages were case insensitive. Now, if you choose insensitivity, you have to suffer recriminations from some users and have to justify why you don’t do as C does. It looks like programmers are getting more conservative nowadays. Personally, I have used case sensitive and case insensitive languages without any problems. In both case, I write code in an insensitive way, following the style guide if it exists. Using case to differentiate identifiers is really the wrong thing to do. So, I can switch between Python and Nim without any difficulty despite Python being case sensitive (which, I think, is not the best choice for a language with implicit declaration). Of course, case sensitivity is simpler for the user but may cause lot of problems later if someone misuses it. And we can be sure, it will happen. So case insensitivity is a better choice to avoid any problem. The only drawback are possible variations in the spelling of identifiers, but it can be solved with appropriate tools. So, no vote for me. There are most important topics and this case sensitivity vs case insensitivity topic tends to become a little too much of a religious affair.
Re: Previously working threaded procedure not working in 0.19
Try `nim devel`, it contains a bugfix for this, that was also backported into 0.19.2 (release pending).
Re: Should we get rid of style insensitivity?
I'm against changing this, and I think a vote is superfluous so **I do not want a vote**. When I first found Nim I though the style insensitivity was a bit strange. But the more I use it the more I like it. And after having had to write some code in C and Ruby that doesn't have it I'm even more for it. The fact of the matter is that you will never be able to get 100% of people to write in one style (and even if you did, is it dataBase or database, fileName or filename?), so all code that isn't style insensitive will be at risk of ending up as a mixed style project. It only takes one "bad" import. Sure you can fix this by making a lot of bindings, but why would you, when you can have style insensitivity for free. Besides, apart from the ubiquitous object/instance differentiation (which Nim also has an exception for) it's widely regarded to be a bad idea to have style-sensitive identifiers anyways. Having a variable fileName and a procedure filename would just be confusing. The only case that can be made here is that an identifier like word1_word2 would collide with wo_rd1word2 which is a problem for a very small set of word combinations where both would be normal names but not the same. Couldn't think of any example of this though. Besides style sensitivity is a relatively new concept. The only reason we have snake-case is because spaces can't be used in identifiers, and the only reason we have upper case letters as separate characters is that the ASCII group decided that it would result in safer encoding. The alternative was sending "Hello" as "Hello". The choice was made as missing the would mean the entire rest of the document would be upper-case, which would be annoying.
Re: What'd I miss?
The `func` is more funky now. The `future` is now `sugar`. `httpbeast` is fastest Server (for JSON data). A lot of cool modules on Nimble.
Re: Nim Fibers?
I agree, but I do think it is a bit funny that you view your gadget as a blocking feature and fibers as something much less important. Both are equally "gadget"-y, as none are really needed for async io. Callbacks/promises/futures and optional posix threads will get you there. In my view, fibers solve async io much better than async/await. Fibers look and feels like a thread and do not infect codebase with async/await constructs all over the place. And both can be made equally performant. Is fibers critical, no. I think 1.0 is much more critical. A possible future fiber implementation depend on a stable 1.0 as you put it.
