July 11
On Thu, Jul 11, 2019 at 08:35:51AM +0000, bauss via Digitalmars-d-announce wrote:
> Great work but the name of "arsd.http2" might be confusing to some because of "HTTP 2" being an actual thing but that module has nothing to do with it and is actually about Open SSL.

That module is about HTTP, openssl is just an (optional) implementation
detail for one aspect of it.

But yeah, I've had to add to the documentation that it implements http 1.1, not http 2.0. My old http module is prolly deprecated long enough now I can just kill it and rename it, but meh, http 2 servers MUST implement http/1.1 as well (and provides zero benefits to me personally), so I see no pressing need to implement it.

Regardless though, I'm kinda tempted to change the name, but it is a hassle. If it was 2013 and I was doing this over again, I'd probably have chosen like "httpclient" instead... but too late for that now.

July 11
On Tuesday, 9 July 2019 at 13:12:22 UTC, Guillaume Piolat wrote:
> On Tuesday, 9 July 2019 at 12:31:15 UTC, Adam D. Ruppe wrote:
>> On Tuesday, 9 July 2019 at 12:09:14 UTC, Greatsam4sure wrote:
>>> I don't know much about this project but l which to know more.
>>
>> My code is the oldest continuously maintained web library in D, started in 2008 and still developed today. It also does a bunch of other things like gui too.
>>
>
> And dom.d is also one of the longest, still _working_ XML parser that is easy to use.
> Longevity and availability have value.

Diamond has XML parsing and HTML parsing too (Not sure how well it works but it should.)

And also CSS3 selector parsing (still not CSS parsing though.)

https://github.com/DiamondMVC/Diamond/tree/master/dom
https://github.com/DiamondMVC/Diamond/tree/master/html
https://github.com/DiamondMVC/Diamond/tree/master/xhtml
https://github.com/DiamondMVC/Diamond/tree/master/xml

https://github.com/DiamondMVC/Diamond/tree/master/css
July 11
On Thursday, 11 July 2019 at 13:14:47 UTC, bauss wrote:
> And also CSS3 selector parsing (still not CSS parsing though.)

dom.d has some of that too. My css3 support is decent but not 100%, it includes :not, :has, :nth-child, nth-of-type and more.

I never implemented :only-child though, that'd be easy to add, I should just do it.

I also have some css parsing, but it isn't amazing. see: http://dpldocs.info/experimental-docs/arsd.dom.StyleSheet.html

you load a stylesheet, then apply it to a document, then can go through their computedStyle properties. It is weird but I've used it before for rendering html to text with color support and stuff like that.

The file html.d also includes one of those css nested expanders, so like

.myclass {
  span {
    color: blue;
  }
}

expands out, this is on dub as `cssexpand`, but I haven't actually used it for years - I no longer believe in css preprocessors...
July 11
On Thursday, 11 July 2019 at 13:24:02 UTC, Adam D. Ruppe wrote:
> On Thursday, 11 July 2019 at 13:14:47 UTC, bauss wrote:
>> And also CSS3 selector parsing (still not CSS parsing though.)
>
> dom.d has some of that too. My css3 support is decent but not 100%, it includes :not, :has, :nth-child, nth-of-type and more.
>
> I never implemented :only-child though, that'd be easy to add, I should just do it.
>
> I also have some css parsing, but it isn't amazing. see: http://dpldocs.info/experimental-docs/arsd.dom.StyleSheet.html
>
> you load a stylesheet, then apply it to a document, then can go through their computedStyle properties. It is weird but I've used it before for rendering html to text with color support and stuff like that.
>
> The file html.d also includes one of those css nested expanders, so like
>
> .myclass {
>   span {
>     color: blue;
>   }
> }
>
> expands out, this is on dub as `cssexpand`, but I haven't actually used it for years - I no longer believe in css preprocessors...

Quick question.

Most of the modules in arsd can be used separately right? Or at the very least dependencies within arsd only, right?
July 11
On Tuesday, 9 July 2019 at 02:32:22 UTC, Adam D. Ruppe wrote:
> ask me anything you like

First of all very this nice and I have been using some of your work like terminal.d with very success!

Second: I remember one of Bjarne's talk about creating some levels in C++ for getting things easily, it would be like packages for entrance level: Starter, Medium, Professional etc.

Do you think that your libraries could fill this gap for D?

Matheus.
July 11
On Thursday, 11 July 2019 at 13:36:17 UTC, bauss wrote:
> Most of the modules in arsd can be used separately right?

Yes, my policy is that the modules use no more than two other modules total.

The ones below with a star* indicate default reliance upon a common C library too, like openssl. I try to avoid these too, but I'm not as strict about it.

foundation modules (0 imports):

cgi.d (though some individual functions, if used, will import more), http2.d*, color.d, database.d, dom.d, jsvar.d, joystick.d, simpleaudio.d, argon2.d*, characterencodings.d and more.

next level (relies only on a foundation module):

simpledisplay.d, png.d, sqlite.d*, postgres.d*, mysql.d*, mssql.d*, bmp.d (etc), script.d. And more.

I also put minigui.d in this category, though it technically has two dependencies - simpledisplay.d, and through it, color.d, but still. nanovega.d is also on the same level as minigui, though if you use the image loader, it will pull in much more.

next level (combines two modules in some way):

database_generation.d, webtemplate.d, gamehelpers.d, web.d (which is my old web framework).



So yeah, you can see the majority of them have zero imports, then most the rest have only one. Only a few do more than that by default.

I say "by default" because in some cases, if you use other functions, it will import more. For example, dom.d's `Document.fromUrl` will implicitly import http2.d, or `parseGarbage` requires arsd.characterencodings, but if you don't use those functions, it will work by itself too.


This is basically my solution to dependency management: just have nothing to manage! (similarly, my approach to version management is to just very rarely break compatibility. My desktop tends to run ~6 month old dmd and my laptop tends to run ~1 year old dmd too, so I have broad compatibility with dmd versions as well.)
July 11
On Thursday, 11 July 2019 at 13:51:03 UTC, Adam D. Ruppe wrote:
> foundation modules (0 imports):

oh, I forgot terminal.d in here.

It is fun to combine the event loops of some of these, since I refuse to put a common interface in since that means another module. It tends to be implemented with template functions that talk to each other.

Similarly, the @scriptable annotation's canonical definition is in jsvar.d - it indicates compatibility with that (though it is mostly used through script.d, jsvar is the foundational data type for the script language, so a lot of the script's runtime logic is actually in there), but it is privately redefined as a string in a few different modules, so they work together without needing to import each other.

color.d and database.d are the two where I actually put in a new module to get a common interface. color.d because images and windows needed it, and database.d of course for those drivers.

I sometimes regret it... simpledisplay.d was so cool when it worked by itself, and now I have better techniques to decouple, but eh, it has used color.d since like 2011 now so oh well.

I also sometimes want to put in a foundational exception module. But again, it breaks my one import rule soooo yeah.
July 11
On Thursday, 11 July 2019 at 13:40:50 UTC, matheus wrote:
> Do you think that your libraries could fill this gap for D?

Possibly. So I'm trying to convince my bosses at work to let me use D on the core product and one of the points I made is that D is really easy for new devs to use.

Part of my strategy is to bundle everything in one place. You download this zip and it just works - the compiler is included, the libs are included, the main code, and even a test database. They haven't looked at it yet.... but in all my own tests, it legitimately just works. You can start playing around with it in a matter of minutes.

I sometimes think about doing basically the same thing for open source D users too. Package my libs in with the compiler, a sqlite and openssl binary build so those just work too, and then some cute examples to get started. I imagine it'd be pretty easy and since my stuff covers such a broad range - terminal, gui, game, web, etc. - there'd likely be something fun in there for anyone.

I even wrote a bunch of basic games as simpledisplay examples: http://dpldocs.info/experimental-docs/arsd.simpledisplay.html#pong so a fun little thing to start with there.

I just haven't actually gotten around to trying it.


Just on the other hand, I don't do much marketing at all so even if it was perfect nobody would know about it lololol
July 11
On Thursday, 11 July 2019 at 14:09:09 UTC, Adam D. Ruppe wrote:
> On Thursday, 11 July 2019 at 13:40:50 UTC, matheus wrote:
>> Do you think that your libraries could fill this gap for D?
>
> Possibly. So I'm trying to convince my bosses at work to let me use D on the core product and one of the points I made is that D is really easy for new devs to use.
>

An important aspect here is the eco system. If you can show that it also has a nice IDE (e.g. Intellij IDE) that's a plus point. The next question which will come: how it integrates with the existing build system / build artefact repository. Also can the unittest results, linter and coverage results displayed and even further evaluated (e.g. Jenkins or SonarQube).
From a management point of view these are important points.
D is getting better and better here, but is a slow process.

Kind regards
Andre
Next ›   Last »
1 2