They basically allow you to use attributes on interfaces to define a type-safe wrapper around any REST interface, then instantiate a connection to it for making calls.
No more manual HttpClient fiddling!
Since it requires only .NET 1.4, you can basically run it on any platform as it’s supported covered by the implementations .NET Core, Mono and the full .NET Framework.
Quite a lot of projects already use it; I got there via the first link:
Ah, C. The best lingua franca we have… because we have no other lingua francas. Linguae franca. Surgeons general? C is fairly old — 44 years, now! — and comes from a time when there were possibly more architectures than programming languages. It works well for what it is, and what it is is a relatively simple layer of indirection atop assembly. Alas, the popularity of C has led to a number of programming languages’ taking significant cues from its design, and parts of its design are… slightly questionable. I’ve gone through some common features that probably should’ve stayed in C and my justification for saying so. The features are listed in rough order from (I hope) least to most controversial. The idea is that C fans will give up when I call it “weakly typed” and not even get to the part where I rag on braces. Wait, crap, I gave it away.
A network graph with more than a thousand programming languages connected by influence relations. Highly influential languages like Lisp, Smalltalk, C, Java, Pascal, C++, Haskel or Python are shown as larger circles as compared to languages with little influence on others like PHP or Argh!. / The influence relation data was retrieved from Freebase in 2013. This design available on posters and other products. An awesome gift for programmers who are into digital art. • Also buy this artwork on wall prints, apparel, kids clothes, and more.
[WayBack] Eric Grange (of [WayBack] DWS and [WayBack] beginend.net fame) mentions he tends to use 1.5, it is about as good as 2 for small lists, but reduces waste for large ones. He also uses a constant delta to accelerate growth early on, so something like:
FastMM small block allocator sizes (size includes the leading header) are: 8, 16, 24, 32, … 160 (in +8 steps), 176, 192, … 320 (+16), 352, 384 … 480 (+32), 528, 576, … 672 (+48), 736, 800, 880, 960, 1056, 1152, 1264, 1376, 1504, 1648, 1808 , 1984, 2176, 2384. [FastMM4.pas, SmallBlockTypes global var]
While the size of reallocated region fits inside a small block (with a different size than a previous block), the data is moved around (new block is allocated from a new suballocator). If it is too big (>2384 bytes), it gets allocated from the medium block allocator (which handles all block sizes up to 264752 bytes; larger blocks come directly from VirtualAlloc).
When small blocks are reallocated (to a larger size), allocator always allocates at least 100% + 32 bytes larger block, even if less is requested by the RTL (example: 8 bytes will grow to 2*8 + 32 = 48 bytes). When medium blocks are reallocated, allocator always allocates at least 125% of the old size. This boosts the performance when blocks are enlarged by small values as they can be enlarged “in place” (no data moved around, just the header is adjusted).
Stefan Glienke and Primož Gabrijelčič then concluded that:
Resizing an array from say 4 elements (pointer size) to 1000 (in multiple steps) will for sure move several times when jumping from one region into the next larger one.
Changing to a growth factor of 1.5 vs 2 won’t change anything in terms of memory fragmentation in FastMM4.
I recently experimented with different grow factors and while the memory fragmentation can only mitigated for medium and large blocks (where it actually matters imo) it might be beneficial to only grow by 1.5 at that point. But that has yet to be tested.
What I liked so far is the grow strategy that Go uses (2x until 1024, 1.25x after that) – see https://golang.org/src/runtime/slice.go#L115
Since you usually set the size upfront if you add many elements at once (well, if you know how many beforehand) the grow strategy only matters in the long run. You want to balance speed (too many realloc might slow things down unnecessarily), memory overhead (if you are overallocating much you risk wasting too much memory) and memory fragmentation (which might happen with a grow factor bigger than the golden ratio)
The trick comes down to enabling the PreferExternalManifest registry setting and then create a manual manifest for the application that forces the application to use “bitmap scaling” by basically telling it does not support “XP style DPI scaling”.
You name manifest file named after the exe and stored it in the same directory as the exe.
After that, you also have to rename the exe to a temporary name and then back in order to refresh the cache.
A quote from the trick:
In Windows Vista, you had two possible ways of scaling applications: with the first one (the default) applications were instructed to scale their objects using the scaling factor imposed by the operating system. The results, depending on the quality of the application and the Windows version, could vary a lot. Some scaled correctly, some other look very similar to what we are seeing in SSMS, with some weird-looking GUIs. In Vista, this option was called “XP style DPI scaling”.
The second option, which you could activate by unchecking the “XP style” checkbox, involved drawing the graphical components of the GUI to an off-screen buffer and then drawing them back to the display, scaling the whole thing up to the screen resolution. This option is called “bitmap scaling” and the result is a perfectly laid out GUI.
In order to enable this option in Windows 10, you need to merge this key to your registry:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide]
"PreferExternalManifest"=dword:00000001
Then, the application has to be decorated with a manifest file that instructs Windows to disable DPI scaling and enable bitmap scaling, by declaring the application as DPI unaware. The manifest file has to be saved in the same folder as the executable (ssms.exe) and its name must be ssms.exe.manifest. In this case, for SSMS 2014, the file path is “C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\Ssms.exe.manifest”.
Paste this text inside the manifest file and save it in UTF8 encoding:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This “Vista style” bitmap scaling is very similar to what Apple is doing on his Retina displays, except that Apple uses a different font rendering algorithm that looks better when scaled up. If you use this technique in Windows, ClearType rendering is performed on the off-screen buffer before upscaling, so the final result might look a bit blurry.The amount of blurriness you will see depends on the scale factor you set in the control panel or in the settings app in Windows 10. Needless to say that exact pixel scaling looks better, so prefer 200% over 225% or 250% scale factors, because there is no such thing as “half pixel”.
Searching for the below error message didn’t reveal useful results.
Error: missing `server' JVM at `C:\Program Files (x86)\Java\jre1.8.0_111\bin\server\jvm.dll'.
Please install or use the JRE or JDK that contains these missing components.
Elasticsearch ships with default configuration for running Elasticsearch on 64-bit server JVMs. If you are using a 32-bit client JVM, you must remove -server from jvm.options and if you are using any 32-bit JVM you should reconfigure the thread stack size from -Xss1m to -Xss320k.
I had a 32-bit JRE installation as browsers usually are 32-bit and that’s what my Java need originated from.
So I edited config\jvm.options with this change:
49a50,51
> ## see https://www.elastic.co/guide/en/elasticsearch/reference/current/setup.html
> ## prevent errors like Error: missing `server' JVM at `C:\Program Files (x86)\Java\jre1.8.0_111\bin\server\jvm.dll'.
51c53
< -server
---
> # -server
Note I left out the -Xss1m change out as that entry wasn’t present in config\jvm.options (which is odd, but hey: documentation is always behind on code).
In a server environment, I’d probably not run Elasticsearch on Windows but on Linux and there all my software is x64 so the error should not happen.
Solving the 2 gigabyte memory limit
Immediately after trying this, I got an error about memory size:
Error occurred during initialization of VM
Could not reserve enough space for 2097152KB object heap
The reason is that in the same config\jvm.options file, elasticsearch reserves 2 gigabyte of heap space which on either experimental or 32-bit systems is an enormous amount of memory. So I made this change:
I have installed ES 5.0.0 Alpha 3 and try to start it up. However, it gives me the following result.
Error: missing `server' JVM at `C:\Program Files (x86)\Java\jre1.8.0_91\bin\server\jvm.dll'.
Please install or use the JRE or JDK that contains these missing components.
It didn’t happen to my another version of ES. Is there any errors for it?
does this work now? This seems to be a problem with Oracle JRE on Windows. The respective page6says:
jre\bin\server\
On Microsoft Windows platforms, the JDK includes both
the Java HotSpot(TM) Server VM and Java HotSpot Client VM.
However, the Java SE Runtime Environment for Microsoft Windows
platforms includes only the Java HotSpot Client VM. Those wishing
to use the Java HotSpot Server VM with the Java SE Runtime
Environment may copy the JDKs jre\bin\server folder to a
bin\serverdirectoryin the Java SE Runtime Environment. Software
vendors may redistribute the Java HotSpot Server VM with their
redistributions of the Java SE Runtime Environment.
I suggest you just install a JDK. Then you should be fine (or you use the workaround they suggest).
bin\server\ On Microsoft Windows platforms, the JDK includes both
the Java HotSpot™ Server VM and Java HotSpot
Client VM. However, the Java SE Runtime Environment
for Microsoft Windows platforms includes only the
Java HotSpot Client VM. Those wishing to use the
Java HotSpot Server VM with the Java SE Runtime
Environment may copy the JDK's jre\bin\server folder
to a bin\server directory in the Java SE Runtime
Environment. Software vendors may redistribute the
Java HotSpot Server VM with their redistributions of
the Java SE Runtime Environment.
RetinaMBPro1TB:~ jeroenp$ brew update
error: unable to unlink old 'Library/ENV/pkgconfig/10.11/libcurl.pc' (Permission denied)
error: unable to unlink old 'Library/ENV/pkgconfig/10.11/libxml-2.0.pc' (Permission denied)
error: unable to unlink old 'Library/ENV/pkgconfig/10.11/sqlite3.pc' (Permission denied)
To restore the stashed changes to /usr/local run:
'cd /usr/local && git stash pop'
Already up-to-date.
This is how I solved it:
RetinaMBPro1TB:~ jeroenp$ ls -al /usr/local | grep -w Library
drwxr-xr-x+ 11 jeroenp admin 374 Mar 9 19:33 Library
RetinaMBPro1TB:~ jeroenp$ sudo chown -R $USER /usr/local/Library/
Password:
RetinaMBPro1TB:~ jeroenp$ brew update
To restore the stashed changes to /usr/local run:
'cd /usr/local && git stash pop'
Updated Homebrew from d32996d to 638d755.
==> New Formulae
...
==> Updated Formulae
...
==> Renamed Formulae
...
==> Deleted Formulae
...
RetinaMBPro1TB:~ jeroenp$
After that, I could install plantuml (which requires java, just so you know) so now I can create SVGs from it locally:
plantuml -tsvg PSO.network-diagram.PlantUML.txt
Note I had to edit the formula so it installs plantuml-8037 or higher (the git version back then installed plantuml-8031) as it fixed a namespace bug. Since plantuml releases often, be prepared to do some version fiddling.
string sender;
sender = "Duda Nogueira";
Programmer: Come on, stop that crap that Java is slow...
Programmer: Wait, I’ll show you my code to prove that Java is not slow. You’ll see it...
Programmer: Wait, the IDE is starting...
Programmer: Just a moment... It’s almost done...
Programmer: Just a little bit... You’ll see how fast it is...
Alex: zzzzzzzz—
T-shirt: Just wait and get a coffee
The Wiert Corner - irregular stream of stuff 