On Friday, 19 January 2024 at 10:15:57 UTC, evilrat wrote:
On Friday, 19 January 2024 at 09:08:17 UTC, Renato wrote:
I forgot to mention: the Java version is using a Trie... and
it consistently beats the Rust numeric algorithm (which means
it's still faster than your D solution
On Friday, 19 January 2024 at 05:17:51 UTC, H. S. Teoh wrote:
On Thu, Jan 18, 2024 at 04:23:16PM +, Renato via
Digitalmars-d-learn wrote: [...]
Ok, last time I'm running this for someone else :D
```
Proc,Run,Memory(bytes),Time(ms)
===> ./rust
./rust,23920640,30
./rust,24018944,147
./r
On Thu, Jan 18, 2024 at 04:23:16PM +, Renato via Digitalmars-d-learn wrote:
[...]
> Ok, last time I'm running this for someone else :D
>
> ```
> Proc,Run,Memory(bytes),Time(ms)
> ===> ./rust
> ./rust,23920640,30
> ./rust,24018944,147
> ./rust,24068096,592
>
On Wednesday, 17 January 2024 at 16:54:00 UTC, H. S. Teoh wrote:
On Wed, Jan 17, 2024 at 07:57:02AM -0800, H. S. Teoh via
Digitalmars-d-learn wrote: [...]
I'll push the code to github.
[...]
Here:
https://github.com/quickfur/prechelt/blob/master/encode_phone.d
T
BTW here's you main
On Wednesday, 17 January 2024 at 16:54:00 UTC, H. S. Teoh wrote:
On Wed, Jan 17, 2024 at 07:57:02AM -0800, H. S. Teoh via
Digitalmars-d-learn wrote: [...]
I'll push the code to github.
[...]
Here:
https://github.com/quickfur/prechelt/blob/master/encode_phone.d
T
Ok, last time I'm
written in D, I can offer
the Eilmer compressible flow solver as an example. This year it
will be ten years that we have been using D to build our flow
solver. It has been a good ride.
There is a blog entry from a couple of years back
https://dlang.org/blog/2022/02/02/a-gas-dynamics-toolkit
On Wednesday, January 17, 2024 7:03:18 AM MST Renato via Digitalmars-d-learn
wrote:
> My main reasoning is that D tools, surprisingly, cannot do
> "Optimize Imports" (turns out that with all the metaprogramming
> going on , it's impossible to tell for sure which imports are
>
On Wednesday, 17 January 2024 at 16:30:08 UTC, H. S. Teoh wrote:
On Wed, Jan 17, 2024 at 07:19:39AM +, Renato via
Digitalmars-d-learn wrote: [...]
But pls run the benchmarks yourself as I am not going to keep
running it for you, and would be nice if you posted your
solution on a Gist
On Wed, Jan 17, 2024 at 07:57:02AM -0800, H. S. Teoh via Digitalmars-d-learn
wrote:
[...]
> I'll push the code to github.
[...]
Here: https://github.com/quickfur/prechelt/blob/master/encode_phone.d
T
--
Why do conspiracy theories always come from the same people??
On Wed, Jan 17, 2024 at 07:19:39AM +, Renato via Digitalmars-d-learn wrote:
[...]
> But pls run the benchmarks yourself as I am not going to keep running
> it for you, and would be nice if you posted your solution on a Gist
> for example, pasting lots of code in the forum makes it
On Wed, Jan 17, 2024 at 07:19:39AM +, Renato via Digitalmars-d-learn wrote:
> On Tuesday, 16 January 2024 at 22:13:55 UTC, H. S. Teoh wrote:
> > used for the recursive calls. Getting rid of the .format ought to
> > speed it up a bit. Will try that now...
> >
>
> T
On Wednesday, 17 January 2024 at 14:49:03 UTC, Sergey wrote:
On Sunday, 14 January 2024 at 23:16:40 UTC, Mike Shah wrote:
[...]
If the talk is related to FOSS, probably it will be worth to
mention:
* GDC project. That D is a part of GCC family and can be easily
used from this toolchain
On Sunday, 14 January 2024 at 23:16:40 UTC, Mike Shah wrote:
Hi D Community,
My talk on how I'm using the D programming language and why I
think it is an excellent language choice for open source
projects will be featured at FOSDEM 2024 at the start of
February 2024 in Brussels, Belgium
function scope
(though there's never going to be a "threshold" everyone agrees
on, I think everyone has one).
My main reasoning is that D tools, surprisingly, cannot do
"Optimize Imports" (turns out that with all the metaprogramming
going on , it's impossible to tell fo
On Tuesday, 16 January 2024 at 19:05:43 UTC, Jonathan M Davis
wrote:
When local imports were introduced, they were pushed as best
practice (in part, because Andrei is a big fan of them), and I
think that for the most part, they still are, but there's
definitely going to be some disagreement
On Wednesday, 17 January 2024 at 11:56:19 UTC, evilrat wrote:
On Wednesday, 17 January 2024 at 11:20:14 UTC, Renato wrote:
That means the input file is still not ASCII (or UTF-8) as it
should. Java is reading files with the ASCII encoding so it
should've worked fine.
It seems that it is
On Wednesday, 17 January 2024 at 11:20:14 UTC, Renato wrote:
That means the input file is still not ASCII (or UTF-8) as it
should. Java is reading files with the ASCII encoding so it
should've worked fine.
It seems that it is only works with ASCII encoding though.
/prechelt-phone-number-encoding/blob/master/benchmark.sh#L31):
```
java -cp "build/util" util.GeneratePhoneNumbers 1000 >
phones_1000.txt
```
Perhaps using this option when running Java will help:
```
java -DFile.Encoding=UTF-8 ...
```
I've used powershell env var to set outp
):
```
java -cp "build/util" util.GeneratePhoneNumbers 1000 >
phones_1000.txt
```
Perhaps using this option when running Java will help:
```
java -DFile.Encoding=UTF-8 ...
```
I've used powershell env var to set output to utf8, D version now
works but java doesn't.
```
java -Xms20M
On Wednesday, 17 January 2024 at 10:24:31 UTC, Renato wrote:
It's not Java writing the file, it's the bash script
[`benchmark.sh`](https://github.com/renatoathaydes/prechelt-phone-number-encoding/blob/master/benchmark.sh#L31):
```
java -cp "build/util" util.GeneratePhoneNumbers 1000 >
that Java generator for these numbers files is
"broken", the resulting count or print runs fine for both Java
and D versions provided in your D branch, but fails with
generated files.
D version complains about bad utf8 encoding.
I've opened the generated file in text editor and it
On Wednesday, 17 January 2024 at 07:06:25 UTC, Renato wrote:
On Tuesday, 16 January 2024 at 22:15:04 UTC, Siarhei Siamashka
wrote:
On Tuesday, 16 January 2024 at 21:15:19 UTC, Renato wrote:
It's a GC allocations fest. Things like this make it slow:
```diff
{
-string digit =
roken",
the resulting count or print runs fine for both Java and D
versions provided in your D branch, but fails with generated
files.
D version complains about bad utf8 encoding.
I've opened the generated file in text editor and it is UTF-16
(little-endian with BOM).
Tried with adoptium jdk
https://issues.dlang.org/show_bug.cgi?id=24179
Dlang Bot changed:
What|Removed |Added
Keywords||pull
--- Comment #3 from Dlang Bot ---
On Tuesday, 16 January 2024 at 22:13:55 UTC, H. S. Teoh wrote:
used for the recursive calls. Getting rid of the .format ought
to speed it up a bit. Will try that now...
That will make no difference for the `count` option which is
where your solution was very slow. To run the slow test
-key-hash-incremental/src/d/src/dencoder.d) time using the same algorithm as Rust ...
[...]
... what I am really curious about is what the code I wrote is
doing wrong that causes it to run 4x slower than Rust despite
doing "the same thing"...
It's a GC allocations fest. Things like
On 1/14/2024 3:16 PM, Mike Shah wrote:
My talk on how I'm using the D programming language and why I think it is an
excellent language choice for open source projects will be featured at FOSDEM
2024 at the start of February 2024 in Brussels, Belgium.
Ehhxcellent!
On Tuesday, January 16, 2024 1:42:04 PM MST bomat via Digitalmars-d-learn
wrote:
> Wow, that was... exhaustive. Thanks for that. :)
> One more question that I have, though...
>
> On Tuesday, 16 January 2024 at 19:05:43 UTC, Jonathan M Davis
>
> wrote:
> > The downsi
On Tue, Jan 16, 2024 at 10:15:04PM +, Siarhei Siamashka via
Digitalmars-d-learn wrote:
> On Tuesday, 16 January 2024 at 21:15:19 UTC, Renato wrote:
[...]
> > ... what I am really curious about is what the code I wrote is doing
> > wrong that causes it to run 4x slower than Rus
On Tuesday, 16 January 2024 at 21:15:19 UTC, Renato wrote:
For the record (I already posted this on GitHub)... here's [my
current fastest
solution](https://github.com/renatoathaydes/prechelt-phone-number-encoding/blob/dlang-key-hash-incremental/src/d/src/dencoder.d) time using the same
On Tue, Jan 16, 2024 at 09:15:19PM +, Renato via Digitalmars-d-learn wrote:
> On Tuesday, 16 January 2024 at 20:34:48 UTC, H. S. Teoh wrote:
> > On Tue, Jan 16, 2024 at 12:28:49PM -0800, H. S. Teoh via
> > Digitalmars-d-learn wrote: [...]
> > > Anyway, I've fixed the
On Tuesday, 16 January 2024 at 21:15:19 UTC, Renato wrote:
I can't explain why it's so incredibly fast, specially for the
`count` case. I tried using the same hashing function on my
solution, but that didn't really help me!
That's dynamic programming with memoization. Basically caching
the
On Tuesday, 16 January 2024 at 20:34:48 UTC, H. S. Teoh wrote:
On Tue, Jan 16, 2024 at 12:28:49PM -0800, H. S. Teoh via
Digitalmars-d-learn wrote: [...]
Anyway, I've fixed the problem, now my program produces the
exact same output as Renato's repo. Code is posted below.
[...]
Great, I ran
Wow, that was... exhaustive. Thanks for that. :)
One more question that I have, though...
On Tuesday, 16 January 2024 at 19:05:43 UTC, Jonathan M Davis
wrote:
The downside of course is that you then have import statements
throughout your code, and they're often going to be duplicated
On Monday, 15 January 2024 at 22:19:56 UTC, Steven Schveighoffer
wrote:
You may have to do the same thing I did with redis:
https://github.com/vibe-d/vibe.d/pull/2372
Good luck! I would also say, I don't know why Windows doesn't
do the same trace info debug thing, except that probably
On Tue, Jan 16, 2024 at 12:28:49PM -0800, H. S. Teoh via Digitalmars-d-learn
wrote:
[...]
> Anyway, I've fixed the problem, now my program produces the exact same
> output as Renato's repo. Code is posted below.
[...]
Oops, forgot to actually paste the code
On Tue, Jan 16, 2024 at 06:54:56PM +, Renato via Digitalmars-d-learn wrote:
> On Tuesday, 16 January 2024 at 16:56:04 UTC, Siarhei Siamashka wrote:
[...]
> > You are not allowed to emit "1" as the first token in the output as
> > long as there are any dictionary word
On Tuesday, January 16, 2024 6:19:59 AM MST Orfeo via Digitalmars-d-learn
wrote:
> I found myself a bit perplexed when it comes to the usage of
> "nested imports" and selective imports. It seems that prominent D
> programmers have varied opinions on the matter. I would
e numeric
approach, while people coming from lower level languages tend to
use a data structure like Trie (if they don't know Trie, they
come up with something similar which is fascinating), which is
harder to implement but more efficient in general.
Can I ask you why didn't you use the [
On Tuesday, 16 January 2024 at 15:50:35 UTC, H. S. Teoh wrote:
Unfortunately there seems to be some discrepancy between the
output I got and the prescribed output in your repository. For
example, in your output the number 1556/0 does not have an
encoding, but isn't "1 Mai 0" a valid encoding
P.S. Compiling my program with `ldc -O2`, it runs so fast that I
couldn't measure any meaningful running time that's greater than startup
overhead. So I wrote a helper program to generate random phone numbers
up to 50 characters long, and found that it could encode 1 million phone
numbers in 2.2
On Tue, Jan 16, 2024 at 07:50:35AM -0800, H. S. Teoh via Digitalmars-d-learn
wrote:
[...]
> Unfortunately there seems to be some discrepancy between the output I
> got and the prescribed output in your repository. For example, in your
> output the number 1556/0 does not have an
On Mon, Jan 15, 2024 at 08:10:55PM +, Renato via Digitalmars-d-learn wrote:
> On Monday, 15 January 2024 at 01:10:14 UTC, Sergey wrote:
> > On Sunday, 14 January 2024 at 17:11:27 UTC, Renato wrote:
> > > If anyone can find any flaw in my methodology or optmise my code so
On Tuesday, 16 January 2024 at 12:28:35 UTC, Bastiaan Veelo wrote:
On Monday, 15 January 2024 at 00:49:25 UTC, matheus wrote:
On Sunday, 14 January 2024 at 23:16:40 UTC, Mike Shah wrote:
[...]
[...]
[...]
Hi Mike are you sure the link is right, or you're on that list?
The main track in
On Tuesday, 16 January 2024 at 13:19:59 UTC, Orfeo wrote:
I found myself a bit perplexed when it comes to the usage of
"nested imports" and selective imports. It seems that prominent
D programmers have varied opinions on the matter. I would love
to hear your insights and e
On Tuesday, 16 January 2024 at 13:37:59 UTC, user1234 wrote:
Implementation detail. D frontend resolves identifiers using
associative arrays (that's called symtabs in the compiler
IIRC), hence the only complexity is the scope (plus the import
decls found while going back to the module scope
On Tuesday, 16 January 2024 at 13:19:59 UTC, Orfeo wrote:
I found myself a bit perplexed when it comes to the usage of
"nested imports" and selective imports. It seems that prominent
D programmers have varied opinions on the matter. I would love
to hear your insights and e
Yes, I try to place my imports at the most general location that makes
sense.
Sometimes that is at the module level, other times its in a single function.
Or anywhere in between (such as a struct).
I found myself a bit perplexed when it comes to the usage of
"nested imports" and selective imports. It seems that prominent D
programmers have varied opinions on the matter. I would love to
hear your insights and experiences on this topic.
Here's a quick summary of what I've come a
On Monday, 15 January 2024 at 00:49:25 UTC, matheus wrote:
On Sunday, 14 January 2024 at 23:16:40 UTC, Mike Shah wrote:
Hi D Community,
My talk on how I'm using the D programming language and why I
think it is an excellent language choice for open source
projects will be featured at FOSDEM
to do the same thing I did with redis:
https://github.com/vibe-d/vibe.d/pull/2372
Good luck! I would also say, I don't know why Windows doesn't do
the same trace info debug thing, except that probably whomever
added it didn't care about windows.
-Steve
that! But for now, my understanding is that the most promising
way to get there would be to write D in `betterC` style?!
I've added port from Rust in the PR comment. Can you please
check this solution?
Most probably it need to be optimized with profiler. Just
interesting how close-enough port
On Monday, 15 January 2024 at 17:45:16 UTC, Steven Schveighoffer
wrote:
Which driver are you using? In the posix driver, it should
mention (and use) the debug flag `EventCoreLeakTrace`.
https://github.com/vibe-d/eventcore/blob/7fa0a15fa541c3fcf65640ee332fd3a09c34730c/source/eventcore/drivers
: 1 socket handles leaked at driver shutdown.
Warning: 1 socket handles leaked at driver shutdown.
```
Unless there's some switch to make it more verbose?
Which driver are you using? In the posix driver, it should
mention (and use) the debug flag `EventCoreLeakTrace`.
https://github.com/vibe-d
On Sunday, 14 January 2024 at 20:36:44 UTC, Steven Schveighoffer
wrote:
There should be a version you can enable that tells you where
that socket handle was allocated. That might give you a further
clue as to why it's not closed when the system shuts down.
I think the program tells you which
On Monday, 15 January 2024 at 00:49:25 UTC, matheus wrote:
On Sunday, 14 January 2024 at 23:16:40 UTC, Mike Shah wrote:
Hi D Community,
My talk on how I'm using the D programming language and why I
think it is an excellent language choice for open source
projects will be featured at FOSDEM
promising
way to get there would be to write D in `betterC` style?!
I've added port from Rust in the PR comment. Can you please check
this solution?
Most probably it need to be optimized with profiler. Just
interesting how close-enough port will work.
On Sunday, 14 January 2024 at 23:16:40 UTC, Mike Shah wrote:
Hi D Community,
My talk on how I'm using the D programming language and why I
think it is an excellent language choice for open source
projects will be featured at FOSDEM 2024 at the start of
February 2024 in Brussels, Belgium
Hi D Community,
My talk on how I'm using the D programming language and why I
think it is an excellent language choice for open source projects
will be featured at FOSDEM 2024 at the start of February 2024 in
Brussels, Belgium.
Look out for the official talk schedule(in the Main Track) here
On Saturday, 13 January 2024 at 20:49:54 UTC, bomat wrote:
I am still getting this in 2024 and vibe.d 0.9.7:
```
Warning: 1 socket handles leaked at driver shutdown.
```
I was wondering if maybe someone has new info on this...
There should be a version you can enable that tells you where
this problem can take minutes even without having to allocate
much memory or print anything.
** I've managed to improve the D code enough that it is now
faster than Common Lisp and the equivalent algorithm in Java.**
It took some profiling to do that, though... thanks to
@Anonymouse
. It's still much slower than Common Lisp and very, very far from Java and Rust.
In the repo is hard to find the proper version.
I've checked the Rust from master branch and it looks a bit
different from D implementation..
I explicitly linked to the Rust implementation in my question:
the [Rust
On Saturday, 13 January 2024 at 11:03:42 UTC, Renato wrote:
I like to use a phone encoding problem to determine the
strenghtness and weaknesses of programming languages because
this problem is easy enough I can write solutions in any
language in a few hours, but complex enough to exercise lots
on
what is actually slow. If you're very good at analysing D,
well-educated hypotheses *may* be enough, until they suddenly
aren't and you will have spent a lot of time on the wrong problem.
Java and Rust.
In the repo is hard to find the proper version.
I've checked the Rust from master branch and it looks a bit
different from D implementation..
I would suggest to rewrite in the same way as Rust implemented.
Probably you would like to try:
* do not use BigInt from std. It could
I am still getting this in 2024 and vibe.d 0.9.7:
```
Warning: 1 socket handles leaked at driver shutdown.
```
I was wondering if maybe someone has new info on this...
On Saturday, 13 January 2024 at 17:00:58 UTC, Anonymouse wrote:
On Saturday, 13 January 2024 at 12:55:27 UTC, Renato wrote:
[...]
Not a great profiling experience :). Anyone has a better
suggestion to "parse" the trace file?
As a drive-by suggestion and I hope it doesn't derail anything,
On Saturday, 13 January 2024 at 12:55:27 UTC, Renato wrote:
[...]
Not a great profiling experience :). Anyone has a better
suggestion to "parse" the trace file?
As a drive-by suggestion and I hope it doesn't derail anything,
but if you have the opportunity to run it on linux, have you
tried
On Saturday, 13 January 2024 at 11:03:42 UTC, Renato wrote:
I tried to profile the D code but the profiler seems to be
broken on my OS (Mac):
I profiled it on Linux and stored [the trace.log
file](https://gist.github.com/renatoathaydes/fd8752ed81b0cf792ed7ef5aa3d68acd) on a public Gist
still need to do all the work, but are not
required to print anything other than how many solutions were
found.
Anyway, I ported the Common Lisp solution to D because, like CL,
D has built-in data structures like associative arrays and
`BigInt` (at least it's in the stdlib)... I thought
Unfortunately, your statements are, by and large, simply wrong.
Not to mention openly hostile.
On Tuesday, 9 January 2024 at 21:25:30 UTC, Lance Bachmeier wrote:
That's not "unverified pre-compiled code". As I said, it's an
import library for Windows, from an attempt long ago to call
anywhere that would allow a developer
to install unverified pre-compiled code from an online repo. It
would pose too much of a security issue.
That's not "unverified pre-compiled code". As I said, it's an
import library for Windows, from an attempt long ago to call R
from D on Windows.
by Weka code. There was an old import
library from when I tried to get embedding of R inside D to
work on Windows.
The updated library generates the R bindings for the user.
There might be something useful there, and the code isn't very
long:
https://github.com/bachmeil/embedrv2/blob/main/inst
On Friday, 5 January 2024 at 05:22:54 UTC, Mike Shah wrote:
On Thursday, 4 January 2024 at 14:17:01 UTC, pizza_dox_
wrote:
On Monday, 14 December 2015 at 10:09:29 UTC, Mike McKee wrote:
I finally managed to get it working, using some help from
this forum and stackoverflow.com, and a little
job at it.
I have updated the package to include a reference to EmbedR
outlining these points. Interestingly enough, there is a Rust
package for R and D interop called embedr as well
(https://docs.rs/extendr-api/latest/extendr_api/).
Here is the updated version of embedr:
https://github.com
On Thursday, 4 January 2024 at 14:17:01 UTC, pizza_dox_ wrote:
On Monday, 14 December 2015 at 10:09:29 UTC, Mike McKee wrote:
I finally managed to get it working, using some help from this
forum and stackoverflow.com, and a little bit of random luck
with tests.
[...]
Hello dlang forum,
https://issues.dlang.org/show_bug.cgi?id=24312
Dennis changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On Monday, 14 December 2015 at 10:09:29 UTC, Mike McKee wrote:
I finally managed to get it working, using some help from this
forum and stackoverflow.com, and a little bit of random luck
with tests.
[...]
Hello dlang forum,
I tried to replicate the shown, but I failed at the dmd compile
On Wednesday, 3 January 2024 at 18:57:44 UTC, ryuukk_ wrote:
I managed to compile your project, ``sgl_context`` is working
for me, it renders and roate
[...]
Wow! Cube and blend work, too?
And on my machine it doesn't rotate, just like I initially
posted.
I had to remove this from
between ABIs.
In fact, it's mentioned by sokol's author below:
I've been seeing weird platform-specific ABI related issues in
language bindings where the struct params were corrupted on
their way to the other language (for instance in Zig on Intel
Macs).
https://github.com/kassane/sokol-d/issues/5
seeing weird platform-specific ABI related issues in
language bindings where the struct params were corrupted on
their way to the other language (for instance in Zig on Intel
Macs).
https://github.com/kassane/sokol-d/issues/5#issuecomment-1875665075
On Saturday, 30 December 2023 at 00:50:54 UTC, data pulverizer
wrote:
I have updated the package to include a reference to EmbedR
outlining these points. Interestingly enough, there is a Rust
package for R and D interop called embedr as well
(https://docs.rs/extendr-api/latest/extendr_api
On Tuesday, 2 January 2024 at 03:31:47 UTC, Steven Schveighoffer
wrote:
On Tuesday, 2 January 2024 at 02:48:29 UTC, Andrej Mitrovic
wrote:
Does anyone know when did named arguments initially land in
the compiler, as part of which release..? I never saw it as a
headline feature in any previous
On Tuesday, 2 January 2024 at 02:48:29 UTC, Andrej Mitrovic wrote:
Does anyone know when did named arguments initially land in the
compiler, as part of which release..? I never saw it as a
headline feature in any previous release notes.
They are not finished yet, which is why they were not
On Monday, 1 January 2024 at 22:02:26 UTC, Iain Buclaw wrote:
Glad to announce D 2.106.1, ♥ to the 4 contributors.
http://dlang.org/download.html
This point release fixes a few issues over 2.106.0, see the
changelog for more details.
http://dlang.org/changelog/2.106.1.html
-Iain
on behalf
Ehhxcellent!
Glad to announce D 2.106.1, ♥ to the 4 contributors.
http://dlang.org/download.html
This point release fixes a few issues over 2.106.0, see the
changelog for more details.
http://dlang.org/changelog/2.106.1.html
-Iain
on behalf of the Dlang Core Team
https://issues.dlang.org/show_bug.cgi?id=24312
Walter Bright changed:
What|Removed |Added
Keywords||ImportC, spec
Component|dmd
---
@WalterBright created dlang/dlang.org pull request #3752 "fix Issue 24312 -
importC: Document workaround for using C symbols wh…" fixing this issue:
- fix Issue 24312 - importC: Document workaround for using C symbols which are
also D keywords
https://github.com/dlang/dlang.org/pull/3752
--
https://issues.dlang.org/show_bug.cgi?id=24312
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #1
On Sunday, 31 December 2023 at 11:12:23 UTC, Mike Parker wrote:
The D Language Foundation's monthly meeting for October 2023
took place on Friday the 13th at 15:00 UTC. It lasted around
one hour and thirty minutes. I was unable to attend, so thanks
to Razvan for running it and to Dennis
On Monday, 1 January 2024 at 10:50:22 UTC, Konstantin wrote:
On Sunday, 31 December 2023 at 11:12:23 UTC, Mike Parker wrote:
Finally, he brought up code-d, [the Visual Studio Code
extension for D](https://github.com/Pure-D/code-d) maintained
by Jan Jurzitza (Webfreak). Steve said
On Sunday, 31 December 2023 at 11:12:23 UTC, Mike Parker wrote:
Finally, he brought up code-d, [the Visual Studio Code
extension for D](https://github.com/Pure-D/code-d) maintained
by Jan Jurzitza (Webfreak). Steve said that it was great when
it worked, but there were a lot of weird things
https://issues.dlang.org/show_bug.cgi?id=24312
Issue ID: 24312
Summary: importC: Document workaround for using C symbols which
are also D keywords
Product: D
Version: D2
Hardware: All
OS: All
tested, and the issue happens again, i don't know what
yielded it to disapear previously, maybe a mistake on my end (i
probably forgot -inline)
Anyways, here is the code that reproduces the issue:
```D
struct InvBoneBindInfo
{
}
struct Test(Value)
{
void test()
{
auto t
On Sunday, 31 December 2023 at 11:12:23 UTC, Mike Parker wrote:
The D Language Foundation's monthly meeting for October 2023
took place on Friday the 13th at 15:00 UTC. It lasted around
one hour and thirty minutes.
[chinese
version](https://fqbqrr.blog.csdn.net/article/details/135319694)
On 01/01/2024 12:12 AM, Mike Parker wrote:
Next, he said he'd discovered that a one-line file with |import
std.file| takes 200ms to compile, and that was nuts. He needed to figure
out at some point exactly what the problem was. It was just semantic
analysis just from the import. He wasn't even
The D Language Foundation's monthly meeting for October 2023 took
place on Friday the 13th at 15:00 UTC. It lasted around one hour
and thirty minutes. I was unable to attend, so thanks to Razvan
for running it and to Dennis for recording it.
Two attendees were first-timers: Adam Wilson
Use https://renderdoc.org/ and check and compare frames for
both your working and non-working example
Nice!! I'll try.
That'll give you an idea at what could be wrong
I suspect you have a typo in one of your definition
I don't doubt it. I'm experiencing D in just a week. (Newbie
On Saturday, 30 December 2023 at 19:27:08 UTC, Matheus Catarino
wrote:
Hi everyone.
Currently I'm working on D binding for sokol project (truly a
dual bindgen [sokol-tools, sokol-header]) which could be merged
into the upstream project.
Sorry if I sidetrack the discussion, but I
301 - 400 of 71210 matches
Mail list logo
