[permalink]2018 ...
januari februari (2) maart (2) april (2) mei (2) juni (3) juli (4) augustus (3) september (3) oktober (2) november (3) december (3)
2018-11-01 17:24
mwjd118
[permalink]
→ TMongoWire commit 78c7c62: jsonDoc v1.1.8
I may have decoupled the bit that works with structured data (using Variants), and converts to/from JSON, into a separate project jsonDoc, and have converted TMongoWire to run on jsonDoc, I also should take the time to update TMongoWide when jsonDoc gets improvements. The fact is I'm doing much more with JSON than on MongoDB recently, so I risk letting this slip out of sight.
What I also should do is set the TMongoWire repository up so it uses the jsonDoc repository as a git module, but for now it's just about one single file so I'll see when I get to it (...).
Don't panic: Bitcoin's usual pre-end-of-year dip is here.
2018-11-23 00:29
btceoy
[permalink]
Don't worry. The price is going down a bit, yes. But I think there's no reason for massive public panic and the cyber-world's equivalent of a run on the bank. The holiday season is here. Black Friday. We need presents for the family, and that costs money. We may have chosen to put the value of our earnings into this new thing designed especially for that, and now need to convert some back to good old local currency, so it probably pushes the exchange rate a bit down. It may even be a good sign of institutionalisation that automated agents kick in and join in on the selling, pushing rates even further down, dramatically so. But it's best for all of us if that's only a marginal effect. If I were speculating, I would guess it would start to look like a buying opportunity, if I could statistically detect when the bottom would come into view, but I am not. Actually I don't care. But since we're guessing, I guess things will bounce back in January. It did last January. Perhaps it won't get to the same levels as we had up till before this dip, but that's OK. If it's all rather stable for a few months, that would be good, but if it follows real events in the real world, that's also good. It's just normal. I'm not worrying. Perhaps next year we'll be paying Christmas gifts in bitcoin. (Though I wouldn't put money on that...)
2018-11-28 22:50
xxm2plan
[permalink]
Should I begin on xxm v2.0? Delphi having a Community Edition is really really great news, not only for all of the Delphi community, but also for me as a hobbyist programmer with a number of freeware opensource projects out there. Except I was one of those that stuck with Delphi 7 up till now, so next to myself being fully convinced to finally take the step, I also need to have a look project-per-project how to lift them into these modern times and upgrade them to full Delphi 10 projects.
One of my darlings is xxm. You can compile xxm with modern Delphi just fine. I switched string to AnsiString or WideString explicitly nearly everywhere, so you shouldn't get as much as a hint. (Except mayby somwhere where I still have case x in ['A'..'Z'] of or something like that where x is a char and thus is a WideChar, and the compiler doesn't like that). But I'm worried about how I chose to set up the project. I thought I was best to just inherit from IUnknown and define a decent interface and build everything around that. But several xxm projects later, some that are even running some decent production load at work, I learned some things, most importantly these two:
It looks like xxm doesn't need to work with object instances. Requests are coming in, something needs to build a response, but having to have your objects set up first before you can get crackin' now appears as something I should have tried to avoid. Specifics and identities are handled by the underlying communication framework anyway, so you can get by with just a reference, and request more with that reference only just when you need it.
The other is that with the dynamics of IUnknown pointers, you're still dragging this COM thing with you. Yes it may be wafer-thin really and proven tech, but it's still something removing you from what really counts: pointers to where the code is to run. If you're really (really!) pushing to get the last drop of jouce from the orange performance-wise, it may be just that last thing that's in the way. Even when you avoid any locking in reference counting.
So this is the big plan for the moment: if I get to put some decent time into the project, over the next year(s), I'm considering starting a blank project xxm 2.0, start with a plain C style interface with just procedure and function pointers — a really really ancient looking interface — that has everything that IXxmContext and related interfaces have now. Then re-start with xxlProto and xxmHttp to make that work, then a new xxmCGI, xxmSCGI, xxmISAPI, xxmAhttpd (and perhaps now really a xxmFastCGI, but no xxm IInternetProtocol any more, sorry) and then have a first new push to see how it performs, with IOCP and http pipelining, and who knows HTTP/2 or HTTP/3 that'll have materialized by then.
After that I was thinking I need a new implementation of IXxmContext that just patches through to the new xxm 2.0 calls, so you can very easily and without a worry add it to an existing xxm v1 project and run it with the xxm v2 handlers, enjoy the performance benifits and slowly change things over to xxm v2 where you need to — or not at all, really.
I hope it's a good plan, but for now it's all a dream. I haven't been able to put much time into my hobby projects lately, but it fluctuates and if it picks up some I'll see how far I'll get. Along the way I still hope to find more people that are searching for a good way to combine good old web-scripting with the power and speed of the Delphi compiler, and can count on xxm to offer good debugging, easy live-updating and a stable and secure platform for their web projects.