go to post Timur Safin · Dec 21, 2022 While I agree that embedding of a yet another web-server into installation of some enterprise software is really a very, very bad idea, increasing a vector of attack, and in the scenario of tightened enterprise install it should be avoided at all costs. But, OTOH, I understand the position of developers using full kit of IRIS (not community edition) for those this immediate Apache removal might lead to significant user experience regression. And it would be rather more preferable to "deprecate" it somehow smoother (e.g. change default to not install, but still keep it as part of a kit for developers installations). But all this sounds like you actually need to have 3 kinds of kits available: - community with PWS enabled by default; - developer version, with all theoretical insecurities, but with convenient goodies integrated (i.e. Apache available, may be with vscode+extensions, and so on); - and tightened, production ready kit, with Apache kit removed.
go to post Timur Safin · Nov 27, 2020 Interesting article, Alexey!But we are still eagerly waiting for the 2nd part, when we should expect it?
go to post Timur Safin · Aug 24, 2019 Could not resist and not mention the fact that I've explained using dynamic JSON objects as "named argument" idiom substitution in Remote proxy objects via dynamic dispatch 3 years ago. Looks like we finally getting the idea :)
go to post Timur Safin · Apr 2, 2019 Sorry for any confusion created - that was only half-baked 1st April joke, as correctly pointed out by Evgeny. I do not have yet such marvelous compiler (with closures, only modern syntax allowed, etc.)!Sorry! :)
go to post Timur Safin · Apr 1, 2019 Well, as all lambdas, they are not silver bullets for those looking for better performance, neither they bring any performance overhead. They are simple syntax sugar for keeping some context close to operation. Nothing magical, but nothing less
go to post Timur Safin · Apr 1, 2019 1st version of this post used C++ style for keeping captured variables, but our small, but agile "design committee" decided to change approach and to use closer to JavaScript syntax here (because it's more natural and wider known to ObjectScript programmers), so see updated post soon.
go to post Timur Safin · Aug 23, 2018 The shorter, not very much serious answer - #dim is recommended by COS Guidelines we used in our local community - COS Guidelines[But well, whom am I tricking about - these rules written by myself, and it was my personal push to use this practice here]Here is the longer question: I hate dynamic typing systems, they tend to break sooner, and they frequently complicate understanding for your team mates. #dim constructs was a small set forward in making COS less dynamic typed, and more static typed language. Originally it was created as a hint for Studio auto-complete, but we always understood that it could be reused for some sort of static analyser (if it would ever be created) which will help find some COS errors rather sooner, at the compile time (or around of compilation time). But these has never materialized (at least it has not happened till last time I checked a couple of years ago). So, if we could not check something automatically, via analysers, we could enforce it manually via policy written to guidelines, and obligatory peer-review before commits...
go to post Timur Safin · Aug 23, 2018 Hear, hear :)P.S.There are always good friends which make me know
go to post Timur Safin · Mar 28, 2017 From that I see in postinstall script the only you need to do with cache.reg - is to create directory, and give it proper permissions 755 mask, i.e.: mkdir -p /usr/local/etc/cachesys/cache.reg chmod 755 /usr/local/etc/cachesys/cache.reg ccontrol create ...
go to post Timur Safin · Mar 28, 2017 Let me be crystal clear and honest - this is horrible[I thought so more than 2 years ago when Max originally published this approach in Russian and still think so today]When you write some code you write it not for yourself, not for being modern and trendy, you write it "for another guy" which will visit it tomorrow. You need to write it as simple as possible, using most obvious approach.If you could write something using same or similar amount of code but without tricky macros then you have to write it simpler and without macros (as here) or without tricky iterators (as in Max case). This complexity just not worth a time your team will loss debugging such code.Please, do not get me wrong - I love JavaScript/TypeScript and all modern things. And would love to apply as expressive constructs as closures in JavaScript or lambdas in C++ (hmm). But they are not here (yet) in the ObjectScript. Many of us tried to lobby for closures addition for ages, but gods of COS had no interest in them.Though, in my personal opinion, implemention of handy closure support would not be much harder than dotted DO statement (and might be based on the same VM token implementation). But I might be wrong in estimation of complexity.