This annotation is documented here but not marked deprecated, however in the migration guide there's no mention of why it was removed, and what should be used instead.
I am totally new to Ktor, and I am supposed to port a 1.6 project to 2 while learning Ktor from scratch. Some leads in this direction will be much appreciated. Thanks
Multiple DSL markers were unified so you can use the KtorDsl annotation instead.
I am trying to implement kotlin multiplaform logger. During the implementation of iOS architecture, I couldn't import os.log to use os_log. How could I do this or what else can I use to log in iOS in Kotlin Multiplatform project?
The problem is that the OSLog class has only Swift API: see here. As Kotlin/Native does not provide direct interoperability, some frameworks are unavailable(see the same problem with SwiftUI for example). The best option you have out-of-the-box is to use NSLog, as Philip suggests, or to use some third-party library. There is a resource with a list of popular Kotlin Multiplatform libraries: https://github.com/AAkira/Kotlin-Multiplatform-Libraries#logging. It might be a good place to start. Two important things to note about this:
This list does not include all libraries. For sure, there are some nice libs that are not included yet.
I'm recommending it as an entry point to the community. Philips' advice is pretty good, and maybe there are some other approaches that can be seen across the libs or in the kotlinlang Slack.
You can simply use kotlin println, also in iOS part you can use platform.Foundation.NSLog for formatter output
Wow, this is totally confusing and the dojo 1.8 documentation seems a complete clusterf**k around build layers. Anybody have a clue what's going on there?
In the build script example profiles, the example amd.profile.js has profile.layers["dojo/dojo"] and the tutorial follows this same syntax.
Besides the tutorial, in the 1.8 build documentation there is no mention of this kind of structure, but of profile.dependencies.layers[n].
The documentation also references non-AMD syntax and, just to add another "layer" of confusion, there's also a profile.dependencies.layers[n].dependencies.
Which should I be using? Is this actually documented anywhere with any consistency or clarity?
I have learned that the Dojo 1.8 Reference Guide contains obsolete information regarding build profiles, but that the Dojo 1.8 Build tutorial is current:
http://dojotoolkit.org/documentation/tutorials/1.8/build/
That tutorial recommends this blog post for more information about layers and build optimization: http://www.sitepen.com/blog/2012/06/11/dgrid-and-dojo-nano-build/
I've noticed that the StyledTextControl (Scintilla basically) in wxWidgets has a great feature that allows multi-selections of text, just like TextMate. However wxRuby doesn't seem to have the function calls to support that feature. I'm wonder if there is a way to enable it or if there might be a way I could rewrite that wrapper to include that function.
It seems strange that they would purposely omit that since they are seemingly pretty exhaustive on most functions calls. Any insight on this would be greatly appreciated. I'm trying to write an open source TextMate clone in Ruby and it's gonna be pretty hard without MultiSelect, I could probably hack something together but it'd be ugly. Thanks ahead of time.
You don't write which version of wxWidgets you are using, but AFAIK only the 2.x versions of the Scintilla library support MultiSelect, which isn't available in stable wxWidgets. wxWidgets 2.8.10 uses Scintilla version 1.70. The SVN trunk uses version 1.75.
i read about the Google Closure Compiler and i will try to use it to make my web application better. But i think it is doing the same things like the dojo shrinksafe.
Has anyone tried to use the Google Closure Compiler for a complex dojo project?
Thanks
Benjamin
Yes, Google Closure Compiler works fine with Dojo projects. Because Closure is derived from Dojo, it has similar concepts (modules, loaders, the build, and so on) so it is potentially possible to use some advanced features of Closure Compiler with Dojo, which go beyond simple minification.
We (Dojo) will evaluate what we can reuse and leverage from Closure and how we can improve interoperability. Obviously it will include all tooling too.
Closure will probably work with any valid javascript code. I fed it an extremely packed, obfuscated version of a complex Prototype project of mine and it spit out a perfectly working version. So even if your code has already been shrinked by Dojo, you can probably use Closure on top of it. You should, however, choose one of the two.
As of Dojo 1.4 (not yet released, but the code is in the subversion trunk of Dojo), you can now use Closure Compiler as an option for the Dojo build process. It takes a bit of setting up. Instructions on how to use Closure Compiler with the Dojo build system.
Dojo 1.6 is compatible (after some minor modifications) with Closure Compiler in Advanced mode.
http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t
Stephen
I happen to have a 12,000 (26,000 if you include dojox/dijit imports) line dojo 1.3.2 application I am about to release.
Well I used the standard dojo build system to throw it all into one lovely big one megabyte file. Then I introduced it to the google closure compiler, the compilation went very well reducing the package down to 350 kb, 100kb less than yahoo ui, and 150kb less than shrinkwrap. I, of course, did it all in advanced mode like a man.
So far so good, then it was time to load it up! The results were mixed. The site did seem to work, but I did get quite a few pesky errors telling me that various things behind the dojo prefix could not be found. I wasn't able to work out exactly what was going on as I didn't have closure addon for firebug ready, but I didn't notice issues the actual operation of the site - though I posit if I looked hard enough I would have found them.
So I thought to myself it appears the closure compiler is renaming dojo name space in my compiled.js to make them inconsistent with dojo.js. It seemed like an ideal solution was to combine dojo.js.uncompressed.js with my blob.js.uncompressed.js using the closure compiler. This resulted in a 51kb reduction in the size of the dojo library so far so good! Bad idea dojo didn't much like this at all and refused to load! It just downloaded then just sat there in protest of google's world domination.
I have done some further research into this matter, from what I read dojo 1.4.0 does support closure in 'simple' mode, but this is rather pointless because as I read closure simple mode provides a similar amount of compression to yui.
Anyway, those are my thoughts, I have looked at closure a little, it looks like a very nice library. The css layout looks drastically simpler than dijit's, this is something I am very fond of, I've often found it easier to rewrite dijits than try and theme them correctly. It seems to be missing some elements of the dojo library I am rather fond of such as dijit._Widget, dijit. _container/contained and of course the famous dojo.declare(). I suppose I could rebuild these, but why should I?
Addition:
Oh it also appears to be lacking a good RPC, cometed framework, and publish/subscriber framework. Unless I am mistaken. Don't get me wrong I want to like closure, I'm not a dojo apologist by any stretch of the imagination, I just like these parts of dojo. The addition of require and provide does make this a serious contender from my perspective. The lack of a meaningful system of this nature drove me away from jquery.