tanya 0.6.0, new containers
Dear community, there is a new release of my gc-free library, tanya. I don't announce each release, so I want to tell short about the latest development and plans for the next releases. The most work in the last time was done on containers. These were added: - DList - Doubly-linked list. - String - UTF-8 string. - Set - The first version of hash based container that holds unique values without a particular order. Currently supports only integral values. Support for more types comes in the next release. - Vector was renamed to Array. The containers support ranges. tanya.memory.types: - Some bug fixes in RefCounted - New Scoped - allocator-aware object wrapper, that destroys the owned object at the end of the scope. The work on the containers will be continued. I also started to rethink the networking and the event loop parts of my library. Trying to extend it I discovered some flaws. So it is a further area, I'm working to provide a more complete networking solution. And it can be that multi-threading will come sooner than I planned originally. And I introduced a short release cycle for the first time: 3 weeks (But I won't flood the forum each time :)). And from now on I'm trying to deprecate features at least for one release before breaking the code to stabilize the code base a bit. https://github.com/caraus-ecms/tanya http://code.dlang.org/packages/tanya https://docs.caraus.io/tanya/
Re: Boston D Meetup for 6/9
On 6/5/17 7:53 AM, Steven Schveighoffer wrote: Hi fellow Boston D enthusiasts. We are going to have another meetup at the Street in Chestnut Hill this Friday. Andrei and I will be there, hope you can join us! Please RSVP on the eventbrite page: https://www.eventbrite.com/e/monthly-boston-d-get-together-tickets-35120523431 This event is cancelled, I will try to reschedule for another day. -Steve
Re: Compile-Time Sort in D
On Friday, 9 June 2017 at 16:50:15 UTC, H. S. Teoh wrote: Yes, please add ctfeWriteln(). ctfeWriteln has it's own set of problems. I resurrected a PR for it a while back. And somewhere along the lines it broke again. newCTFE's debugging facilities which will come later this year, will provide a much better alternative. (though the debugging facilities will only be available using the slow bytecode backend)
Re: Compile-Time Sort in D
On Friday, 9 June 2017 at 15:16:56 UTC, Steven Schveighoffer wrote: On 6/9/17 10:49 AM, Stefan Koch wrote: If I'd had to worry about an interface to runtime code I'd be a little unhappy. I kind of remember you saying at dconf2016 "If only CTFE could write to the filesystem, I could fully support sqlite at compile time!" or something like that. It's amazing how modest your feature requests become once you have to implement them yourself ;))
Re: Compile-Time Sort in D
Steven Schveighoffer wrote: At least in terms of i/o printing to the console or whatnot, it would be cool to be able to do so at compile-time just directly with writeln. As of now, a CTFE function can't call writeln, and it also can't pragma(msg, ...) because it has to be written as a runtime function. yeah, `ctfeWriteln()`, even in very rudimentary form, will be priceless for debugging CTFE code. sure, CTFE code can be called in runtime and debugged, but sometimes it require alot of bouncing back and forth, like "let's replace all `enum` values with `auto` down the code, and then back", 'cause result of one CTFE call may be used in another CTFE call, and so on...
Re: Compile-Time Sort in D
On 6/9/17 10:49 AM, Stefan Koch wrote: On Friday, 9 June 2017 at 12:15:50 UTC, Steven Schveighoffer wrote: [it] can use the *actual* i/o routines [at compile-time] you would use at runtime is pretty impressive. Stefan would have a field day with this power :) Infact I think this would scale pretty badly. I do not want to debug some ctfe which loads dlls and does god what to the environment. Even the restricted form of ctfe D supports is pretty hard to get right. If I'd had to worry about an interface to runtime code I'd be a little unhappy. I kind of remember you saying at dconf2016 "If only CTFE could write to the filesystem, I could fully support sqlite at compile time!" or something like that. At least in terms of i/o printing to the console or whatnot, it would be cool to be able to do so at compile-time just directly with writeln. As of now, a CTFE function can't call writeln, and it also can't pragma(msg, ...) because it has to be written as a runtime function. -Steve
Re: Compile-Time Sort in D
On Friday, 9 June 2017 at 12:15:50 UTC, Steven Schveighoffer wrote: [it] can use the *actual* i/o routines [at compile-time] you would use at runtime is pretty impressive. Stefan would have a field day with this power :) -Steve Infact I think this would scale pretty badly. I do not want to debug some ctfe which loads dlls and does god what to the environment. Even the restricted form of ctfe D supports is pretty hard to get right. If I'd had to worry about an interface to runtime code I'd be a little unhappy.
Re: Compile-Time Sort in D
On Friday, 9 June 2017 at 12:15:50 UTC, Steven Schveighoffer wrote: Stefan would have a field day with this power :) I think he would certainly appreciate an improved ability to debug CTFE code.
Re: Compile-Time Sort in D
On Friday, 9 June 2017 at 12:15:50 UTC, Steven Schveighoffer wrote: On 6/7/17 5:47 PM, John Carter wrote: On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote: https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/ Seems like you have inspired people... http://blog.zdsmith.com/posts/compiletime-sort-in-nim.html That is kind of neat. While I can say that D can perform technically the same feat via pragma(msg, ...) and importing a file directly (would leave a comment on the blog, but there isn't a spot for it), the fact that you can execute arbitrary code in a block at compile time that can use the *actual* i/o routines you would use at runtime is pretty impressive. Stefan would have a field day with this power :) Yeah, it feels C++'y when you need to leave CTFE if you want to print some value computed in CTFE or use it as a name of file to load. :/
Re: Compile-Time Sort in D
On 6/7/17 5:47 PM, John Carter wrote: On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote: https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/ Seems like you have inspired people... http://blog.zdsmith.com/posts/compiletime-sort-in-nim.html That is kind of neat. While I can say that D can perform technically the same feat via pragma(msg, ...) and importing a file directly (would leave a comment on the blog, but there isn't a spot for it), the fact that you can execute arbitrary code in a block at compile time that can use the *actual* i/o routines you would use at runtime is pretty impressive. Stefan would have a field day with this power :) -Steve
Re: Compile-Time Sort in D
On Friday, 9 June 2017 at 01:34:14 UTC, Mike Parker wrote: On Thursday, 8 June 2017 at 19:07:50 UTC, cym13 wrote: Seeing that the one and only D example in the nim article is a broken one (using static instead of enum or static immutable for 'b') we should have started with a correct example before showing the broken one... Good to know for next time. static variables are initialized with compile-time values. They don't need be immutable for that. My bad, I miscopied the code.
Re: Ali's talk C++Now 2017: Competitive Advantage with D on Reddit!
On Thursday, 8 June 2017 at 22:59:00 UTC, Andrei Alexandrescu wrote: Posting direct HN links in any forum is a sure way to have the entry classified as spam (HN uses an algorithm that flags as spam many accesses that do not have their own site as referrer). -- Andrei *uch* What a strange system they use. Good to know for the future. Delete my posts above with the link, so the link is removed. That will solve the issue of people going directly to the article.
