Re: basic py2many.pyd work at language/syntax level in my dlang fork now
On Friday, 12 July 2024 at 19:13:26 UTC, Witold Baryluk wrote: I will take a look more into py2many. I also do hope you complete it, and merge upstream. FYI, now merged into the main branch: https://github.com/py2many/py2many/tree/main/pyd
basic py2many.pyd work at language/syntax level in my dlang fork now
Hi, I have made basic py2many.pyd work at language/syntax level in my dlang fork: https://github.com/mw66/py2many/tree/dlang The following examples works now: https://github.com/mw66/py2many/tree/dlang/tests/expected py2many/ 13:56:23$ ls ./tests/expected/*.d ./tests/expected/bubble_sort.d ./tests/expected/cls.d ./tests/expected/fib.d ./tests/expected/import_tests.d ./tests/expected/classes.d ./tests/expected/dict.d ./tests/expected/hello_world.d ./tests/expected/nested_dict.d Please use this Makefile for local setup and run tests: https://github.com/mw66/py2many/blob/dlang/Makefile I haven't created PR to be merged into the main branch, since it's better to pass all the tests. The remaining work is to make Python's specific feature (e.g. async), library (e.g. complex number, NamedTemporaryFile) work in D. There are many things need to be done, if you have time, you can pick up from my fork, and work from there. (E.g. you can create PR to my branch, and when everything is ready, we submit to the main py2many all together). The more people can help, the faster we can get this done. HTH.
Re: LDC 1.35.0-beta1
On Thursday, 28 September 2023 at 11:13:20 UTC, Hipreme wrote: Hello, don't know when that happened but I'm happy to say that LDC 1.35.0 beta is building in half the time needed when compared against the version I was using (1.32.0). Same experience with the slow 1.32.0, there must be a performance bug in that version somewhere.
Re: Giving up
On Sunday, 7 August 2022 at 00:54:35 UTC, Steven Schveighoffer wrote: Note, we have a complete copy of the git repository. So you mean all the dub registered packages are cached somewhere? Can we publish the cache address?
Re: Giving up
On Friday, 5 August 2022 at 17:56:47 UTC, bachmeier wrote: Here's the code if anyone is relying on it: https://github.com/bachmeil/decimal/tree/main I really think DUB should save a copy of all the files of all the registered packages: https://code.dlang.org/packages/decimal to prevent such disaster in the future. @bachmeier, you want create a new DUB entry?
Re: Archttp 1.0.0 released! Simple, Flexible, Performance! DLang web framework.
On Sunday, 22 May 2022 at 21:08:24 UTC, zoujiaqing wrote:
Archttp is a Web server framework written in D programming
language with Golang concurrency capability. Archttp has an
ExpressJS-like API design, which makes it extremely easy to use.
## Archttp's core focus is on three metrics:
1. Simple
2. Flexible
3. Performance
## Document for Quick Start
https://github.com/kerisy/archttp/blob/main/docs/QuickStart.md
## Usage sample code
```D
import archttp;
void main()
{
auto app = new Archttp;
app.get("/", (req, res) {
res.send("Hello, World!");
});
app.listen(8080);
}
```
## Source Code
https://github.com/kerisy/archttp
How does this lib differ from your hunt lib? different design
goals? Do you want to give a comparison summary?
Re: dmt: Python-like indentation in D programming language
On Wednesday, 17 November 2021 at 17:23:14 UTC, Witold Baryluk wrote: I'm wondering if it can translate existing Python code (e.g with a bit py3 type annotations) to D code, then it may attract much more users. No. And not planned. Sparkling some `auto` here and there manually, makes it quite possible tho. I did port on Python program to `dmt` rather quickly. But of course if you use standard library, things are harder. Just FYI: I found a working Python PEG grammar file here https://github.com/we-like-parsers/pegen/blob/main/data/python.gram it will be a great helper to to trans-compile Python to D. E.g. to try parse Python code and execute the parsed code: ``` git clone https://github.com/we-like-parsers/pegen cd pegen make demo ``` (I did that PR :-)
Re: dmt: Python-like indentation in D programming language
On Tuesday, 16 November 2021 at 21:58:24 UTC, Witold Baryluk wrote: Hi, `dmt` is an old project of mine from around year 2006. I ported it recently from D1 to D2, and added some extra features and support for extra keywords, and fixed few bugs here and there. `dmt` is a converter (offline or auto-invoking compiler after conversion) from Python-like indention style to curly braces for D programming language. https://github.com/baryluk/dmt To be frank, by just Python syntax alone I wasn't sure how many people want to try it. I'm wondering if it can translate existing Python code (e.g with a bit py3 type annotations) to D code, then it may attract much more users. What I have also in mind is numpy program to lib Mir.
Re: nbuff v0.1.13
On Tuesday, 25 May 2021 at 13:13:52 UTC, ikod wrote: Hello, This is buffer management library. I created it for my networking daemons and recently it was used in Nats client (https://code.dlang.org/packages/nats), and maybe it can be useful for others, so I added small tutorial. The main features are: nogc, safety, zero copy (actually sometimes copy required), automatic buffer management and reuse through thread-local buffer pool. Here is tutorial link: https://github.com/ikod/nbuff/blob/master/docs/tutorial-e.md Here is link to main repo https://github.com/ikod/nbuff This is great! Thanks for the contribution to the D community. Your other library request is one of the highest rated library on dub registry. BTW, since you're an expert on networking. I'm just wondering if you have time to help with this long standing issue: https://github.com/huntlabs/grpc-dlang/issues/15 I.e. making grpc Python / D as server/client can talk to each other. A few people, including me, are waiting for this issue to be fixed. Without the fix, D rpc is living in one-man's island. You help will be highly appreciated!
Re: Debugging improvements - Visual Studio Natvis, GDB, LLDB
On Saturday, 24 April 2021 at 18:32:42 UTC, Gavin Ray wrote: On Tuesday, 6 April 2021 at 21:04:47 UTC, WebFreak001 wrote: I have created editor independent pretty printers / visualization files for Visual Studio's debugger\*, GDB and LLDB. [...] Incredible -- below in VS Code (with launch.json and dub.json config as shown on right) I am able to see arrays, strings, and associative arrays keys/values! Are you running on Windows or Linux?
Re: Debugging improvements - Visual Studio Natvis, GDB, LLDB
On Saturday, 24 April 2021 at 17:44:39 UTC, WebFreak001 wrote:
On Saturday, 24 April 2021 at 17:16:48 UTC, mw wrote:
On Saturday, 24 April 2021 at 16:08:07 UTC, WebFreak001 wrote:
those are GDB-MI commands. If you can only run GDB console
commands you can use
```
source /path/to/gdb_dlang.py
enable pretty-printer
```
Thanks, I put these 2 lines into .gdbinit, and it seems loaded.
I have a question about print AA: it only print values?
```
11 int[int] aa = [1:2, 2:4];
(gdb) p aa
$1 = [2] = {4, 2}
(gdb) p aa[1]
Invalid binary operation specified.
```
I tried both dmd -g and ldc2 -g on Linux, both the same
behavior.
I haven't modified the expression parsing behavior (I don't
know if I can even do that), it's only pretty printers
Why they (keys & values) are showing below in VS code?
Incredible -- below in VS Code (with launch.json and dub.json
config as shown on right) I am able to see arrays, strings, and
associative arrays keys/values!
The implementations are different? or there are fundamental
obstacles that cannot be done for GDB console?
Re: Debugging improvements - Visual Studio Natvis, GDB, LLDB
On Saturday, 24 April 2021 at 16:08:07 UTC, WebFreak001 wrote:
those are GDB-MI commands. If you can only run GDB console
commands you can use
```
source /path/to/gdb_dlang.py
enable pretty-printer
```
Thanks, I put these 2 lines into .gdbinit, and it seems loaded.
I have a question about print AA: it only print values?
```
11 int[int] aa = [1:2, 2:4];
(gdb) p aa
$1 = [2] = {4, 2}
(gdb) p aa[1]
Invalid binary operation specified.
```
I tried both dmd -g and ldc2 -g on Linux, both the same behavior.
Re: Debugging improvements - Visual Studio Natvis, GDB, LLDB
On Tuesday, 6 April 2021 at 21:04:47 UTC, WebFreak001 wrote: I have created editor independent pretty printers / visualization files for Visual Studio's debugger\*, GDB and LLDB. The script and setup guide are available here: https://github.com/Pure-D/dlang-debug where to input this command? from gdb command line? or in .gdbinit? ``` -enable-pretty-printing -interpreter-exec console "source /path/to/gdb_dlang.py" ``` (sorry, I googled a bit, but didn't find the answer).
Re: Contacting DlangScience maintainers
On Tuesday, 30 March 2021 at 07:51:17 UTC, Chris Piker wrote: Other than rudely posting an issue @ https://github.com/DlangScience/NetCDF-D, does anyone know the right way to start a conversation with DlangScience? I'm trying to blend in and learn this community's norms. try also: https://github.com/dlang-community/discussions/issues But there is not much going on in DlangScience, right now there is no real package maintained. The dlang-community intention is to maintain *orphaned* but useful packages. E.g. one of the most popular package libmir is not in DlangScience at all: https://github.com/libmir/mir-algorithm https://github.com/libmir So https://code.dlang.org/ is the main place for packages, science or not.
Re: Contacting DlangScience maintainers
On Friday, 26 March 2021 at 21:55:18 UTC, Chris Piker wrote: Hi DlangScience I've setup D prototypes for the CDF (Common Data Format) file reading/writing library. Since it's mostly just basic D prototypes for a C library the module's name is deimos.cdf and can be found here: https://github.com/das-developers/deimos.cdf I'm attempting to get the repository hosted within a github organization run by the Goddard Space Physics Data facility. If the SPDF declines to host the repo, could it find a home in the DlangScience organization? I'd be happy to sign up to maintain it. I didn't know that your group existed when I wrote the module or would have contacted you before work began. Instead of responding to this message, please use the Discussion section for deimos.cdf, at least temporarily anyway. Thanks, (cross posted from https://gitter.im/DlangScience/public since that site looks unused) Let's discuss it here: https://github.com/orgs/dlang-community/teams/science/discussions @wilzbach is the maintainer of the group.
Re: Mir vs. Numpy: Reworked!
On Thursday, 3 December 2020 at 21:28:04 UTC, jmh530 wrote: On Thursday, 3 December 2020 at 20:25:11 UTC, data pulverizer wrote: [snip] Very interesting work. What is the difference between Mir's field, slice, native and ndslice? [...] The document says: Slice: Python like. Uses D Slices and Strides for grouping (Red-Black). Naive: one for-loop for each dimension. Matrix-Access via multi-dimensional Array. Field: one for-loop. Matrix is flattened. Access via flattened index. NdSlice: D like. Uses just MIR functionalities. As Andre said: """ What maybe could help python developers is to have some articles showing numpy coding and side by side the equivalent MIR coding. """ I think such Numpy v.s Mir side-by-side equivalent (or improvement) document will greatly boost the adoption of Mir.
Re: Beta 2.094.0
On Monday, 14 September 2020 at 23:36:45 UTC, James Blachly wrote:
On 9/14/20 5:17 PM, mw wrote:
On Sunday, 13 September 2020 at 16:33:42 UTC, James Blachly
wrote:
{
"name": "git-dependency",
"dependencies": {
"gitcompatibledubpackage": {
"repository":
"git+https://github.com/dlang-community/gitcompatibledubpackage.git";,
"version":
"ccb31bf6a655437176ec02e04c2305a8c7c90d67"
}
}
}
On a git repo, where to get this version string?
BTW, pass in "master" does not work.
Looks like the commit hash ; use `git log`
Agree a branch name would be nice , then it could automatically
take HEAD
Actually I just saw this:
https://dub.pm/package-format-json#version-specs
-- Use a GIT branch (deprecated): "~master"
Why it's deprecated? can we revive it?
Re: Beta 2.094.0
On Sunday, 13 September 2020 at 16:33:42 UTC, James Blachly wrote:
{
"name": "git-dependency",
"dependencies": {
"gitcompatibledubpackage": {
"repository":
"git+https://github.com/dlang-community/gitcompatibledubpackage.git";,
"version":
"ccb31bf6a655437176ec02e04c2305a8c7c90d67"
}
}
}
On a git repo, where to get this version string?
BTW, pass in "master" does not work.
Re: Visual D 0.51.0 - semantic engine based on dmd frontend
On Tuesday, 8 September 2020 at 19:36:51 UTC, mw wrote: On Tuesday, 8 September 2020 at 18:42:28 UTC, James wrote: how is the dub support work? i don't understand how to load it in visual studio is there any guide? given you have dub.json build already, ``` C:\\ dub.exe generate visuald ``` then open the generated `proj.sln` file with VisualD https://dub.pm/commandline
Re: Visual D 0.51.0 - semantic engine based on dmd frontend
On Tuesday, 8 September 2020 at 18:42:28 UTC, James wrote: how is the dub support work? i don't understand how to load it in visual studio is there any guide? given you have dub.json build already, ``` C:\\ dub.exe generate visuald ``` https://dub.pm/commandline
Re: Visual D 1.0.1 released
On Sunday, 23 August 2020 at 07:33:01 UTC, Rainer Schuetze wrote: Hi, an update for Visual D has just been made available. Visual D is a Visual Studio extension that adds D language support to VS 2008-2019. The most important part of the update is that the semantic engine is now based on the latest compiler release 2.093.1. There are a few other improvements and bug fixes, e.g. support for navigation with forward/backward mouse buttons and fixed documentation tool tips for template functions. See the full version history here: https://rainers.github.io/visuald/visuald/VersionHistory.html You can download the update installer or the full installer bundled with DMD 2.093.1 and LDC 1.23.0 from https://rainers.github.io/visuald/visuald/StartPage.html Thanks for the update. I just tried, and found two issues: https://issues.dlang.org/show_bug.cgi?id=21193 https://issues.dlang.org/show_bug.cgi?id=21194 Basically, I cannot build unit-threaded_property.lib (saying corrupt MS Coff object) with VisualD, but I can build on Windows using command line: C:\project\dlang\dmd-2.093.1\windows\bin64\dub.exe test --build=unittest
jdiutil v1.0.0: Just-Do-It util mixin, some small util mixin to make (debug) life easier: string interpolation etc ...
On Thursday, 18 June 2020 at 09:00:42 UTC, zoujiaqing wrote:
Now dlang string processing is complex, like this:
We've talked too much on this topic, I've found a number of DIPs,
some string interpolation dub packages, either no-longer
maintained, or does not fit my need. So I decided to just-do-it:
https://code.dlang.org/packages/jdiutil
jdiutil: Just-Do-It util mixin
Some small util mixin to make (debug) life easier:
-- string interpolation for easy debug print: _S with var name;
_s without var name
-- ToString will generate string with class fields content,
instead of just plain pointer.
-- ReadOnly, ReadWrite declare fields without boilerplate code
-- Singleton, Low-Lock Singleton Pattern
https://wiki.dlang.org/Low-Lock_Singleton_Pattern
-- AtomicCounted, atomic counter
Examples, check app.d:
public import jdiutil;
class Point {
// declare fields
mixin ReadOnly! (int, "x");
mixin ReadWrite!(double, "y");
mixin ReadWrite!(string, "label", "default value");
// atomic counter
mixin AtomicCounted;
// this is a Singleton class!
mixin Singleton!Point;
// debug print string helper
mixin ToString!Point;
}
void main() {
int i = 100;
double d = 1.23456789;
Point thePoint = Point.getSingleton();
// multiple vars separated by ';'
// _S with var name; _s without var name
writeln(mixin(_S!"print withvar name: {i; d;
thePoint}"));
writeln(mixin(_s!"print without var name: {i; d;
thePoint}"));
thePoint.incCount();
logger.info(mixin(_S!"works in logger too: {i; d;
thePoint}"));
thePoint.incCount();
string str = mixin(_S!"assign to string with custom
format: {i; d%06.2f; thePoint}");
writeln(str);
}
Output:
print withvar name: i=100 d=1.23457 thePoint=app.Point(_x=0
_y=nan _label=default value _counter=0)
print without var name: 100 1.23457 app.Point(_x=0 _y=nan
_label=default value _counter=0)
2020-06-20T22:31:29.053 [info] app.d:38:main works in logger too:
i=100 d=1.23457 thePoint=app.Point(_x=0 _y=nan _label=default
value _counter=1)
assign to string with custom format: i=100 d=001.23
thePoint=app.Point(_x=0 _y=nan _label=default value _counter=2)
This is my 1st dub package, suggestions welcome (please use the
github issue, easier to track.)
Thanks for everyone on this forum who have helped!
Re: Pretty-printing D arrays with Mir
On Sunday, 31 May 2020 at 23:10:44 UTC, jmh530 wrote: On Sunday, 31 May 2020 at 22:40:09 UTC, tastyminerals wrote: I often print arrays to see how they look and their contents. NumPy has a nice way of pretty-printing the arrays, and I was lacking this in D. ┌ ┐ │┌ ┐│ ││ 1 2 3 4 5 6││ ││ 7 8 9 10 11 12││ │└ ┘│ │┌ ┐│ ││13 14 15 16 17 18││ ││19 20 21 22 23 24││ │└ ┘│ └ ┘ https://github.com/tastyminerals/pretty_d_array Interesting. I had done some work in 2018 for numir format facilities. At the time mir didn’t have a way to do @nogc formatting, but it does now. It might be interesting to either revisit that or think about getting this into mir. Excellent! 👍 D is fun to work with everyday! I literally, oh no, (obviously :-) visually envision Mir will beat numpy one day!
Re: DIP1028 - Rationale for accepting as is
On Monday, 25 May 2020 at 17:31:29 UTC, Paul Backus wrote: Even if you did review your code *and* all of your dependencies, if you did it before DIP 1028 was accepted (i.e., any time in the last 10 years or so), you may have deliberately left external @system functions un-annotated, because @system was the default. In fact, I *know* that people have done this, because I've been running my patched version of the compiler [1] against the dmd, druntime, and phobos codebases, and I have found an enormous number of such un-annotated declarations. Here are just a few of them in druntime: https://github.com/dlang/druntime/pull/3117 Lots and lots of projects in the D ecosystem are going to need similar patches to be compatible with DIP 1028. And I don't think it's realistic to expect people to make these changes without some kind of help from the tooling. [1] https://github.com/dlang/dmd/pull/11176 Can we declare the new D compiler version 3.0 for @safe-as-default? and keep version 2.x compiler for the old @system-as-default? In industries, it is a big-NO-NO to break exiting *working* code base. I've read some past threads talking about the instability of compilers (due to new feature introduced), e.g. in this on_leaving_d thread: https://forum.dlang.org/thread/ncbawciyybdksecur...@forum.dlang.org?page=1 https://gitlab.com/mihails.strasuns/blog/blob/master/articles/on_leaving_d.md Let me quote what D's *industry users* (whose trademark is on the front page of dlang.org) have said 2 years ago: """ But when it comes to be boring and predictable, D fails terribly. You can't assume that released features will become 100% usable (no bugs, sufficient docs and tests, well-defined integration with other language features) even few years after initial release. You can't assume that next compiler upgrade won't suddenly break your project or any of its transitive dependencies. You can't assume that any compiler version will be maintained for more than few months. You can't assume there is any control over how declared vision documents get executed in practice. You can't trust any promises from language authors because they don't keep any track of those. It is anarchy driven development in all its glory. """ I understand the desire of Walter to continue innovation and I appreciate it, and I also think this change from @system to @safe-as default is an important step for D's future direction, as I commented in my thread yesterday: https://forum.dlang.org/post/brvexgjuqkbebizdm...@forum.dlang.org """ -- the recent change @safe as default opt-in is good thing: without a @nogc phobos, nobody is going to write @system level software using D. I think this @safe change means the shift of D's focus from system software to application software. And I'm glad to see the the template project that dub generate starts with "app.d", which is the right direction for D. """ But on the other hand, we also need to take care of our existing D users, esp industry users, are they going to be happy about breaking their working code base with a new compiler version? For example, we can define a metric: say, how many percent of the packages on https://code.dlang.org/ will continue work as-it-is *without* to make any change with the new @safe-as-default compiler. If > 95% of these packages (the 68–95–99.7 three-sigma rule of thumb https://en.wikipedia.org/wiki/68%E2%80%9395%E2%80%9399.7_rule) require not any code change, then go ahead, release the new @safe-as-default compiler as 2.093. Otherwise, I'd suggest to keep 2 versions of compiler: -- version 2.x as stable compiler for (industry) users to use in production, and will only provide bug fixes, but no new language feature (changes) to the compiler. (And I believe the 2.x version D language has already be *feature rich enough* to beat all those Java, C#, and Rust for people to use in production software). -- version 3.x for Walter to experiment and explore new ideas, and warn all the users that version 3 is unstable compiler feature-wise, use-it-at-your-own-risk, your code base may need major change in the future. Thoughts?
Re: Fastest JSON parser in the world is a D project
On Wednesday, 14 October 2015 at 07:35:49 UTC, Marco Leise wrote:
fast.json usage:
auto json = parseTrustedJSON(`{"x":123}`);
Work with a single key from an object:
json.singleKey!"someKey"
json.someKey
Newbie Q: how to get the value?
---
import std.stdio;
import fast.json;
void main() {
auto json = parseTrustedJSON(`{"x":123}`);
writeln(json.x); // shall I get 123 here?
}
---
core.exception.AssertError@/home/xxx/.dub/packages/fast-0.3.5/fast/source/fast/json.d(1208):
Assertion failure
dmd v2.092.0
