2x1=10

because numbers are people, too
Persönliches
Fotografie
Programmierung
    • Dockerized .NET Core 1.0.1 and .NET Framework on Mono 4.7

      TLDR; The set­up is avail­able via GitHub and the you can direct­ly pull the sunside/dotnet Dock­er image.

      Three com­po­nents are used in this process:

      • An Ubun­tu Trusty base image that has libuv installed (required for Kestrel)
      • A mono instal­la­tion that sup­ports .NET 4.6.1
      • .NET Core 1.0.1

      Ubun­tu Trusty’s libuv is pret­ty old, so we’re build­ing it from source. The base image is pret­ty straight­for­ward, just use ubuntu:trusty, install the require­ments for build­ing libuv, as well as a bit of can­dy and then imme­di­ate­ly throw away half of the stuff:

      FROM ubuntu:trusty
      
      RUN LIBUV_VERSION=1.9.1 \
      	&& apt-get update \
      	&& apt-get -y install vim-tiny nano curl wget autoconf automake build-essential libtool \
      	&& curl -sSL https://github.com/libuv/libuv/archive/v${LIBUV_VERSION}.tar.gz | tar zxfv - -C /usr/local/src \
      	&& cd /usr/local/src/libuv-$LIBUV_VERSION \
      	&& sh autogen.sh && ./configure && make && make install \
      	&& rm -rf /usr/local/src/libuv-$LIBUV_VERSION \
      	&& ldconfig \
      	&& apt-get -y purge autoconf automake build-essential libtool \
      	&& apt-get -y autoremove \
      	&& apt-get -y clean \
      	&& rm -rf /var/lib/apt/lists/*
      

      Next step is mono. I’m using night­ly builds here, but any mod­ern instal­la­tion would prob­a­bly work. It’s pret­ty straight­for­ward: mono-devel is required to get the sys­tem libraries (oth­er­wise dotnet restore will be unable to restore frameworkDependencies), the rest is the com­pil­er.

      ENV MONO_VERSION 4.7.0.559
      ENV DEBIAN_MONO_VERSION 4.7.0.559-0nightly1
      
      RUN apt-key adv --keyserver hkp://pgp.mit.edu:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF \
      	&& echo "deb http://download.mono-project.com/repo/debian nightly main" > /etc/apt/sources.list.d/mono-nightly.list \
      	&& apt-get update \
      	&& apt-get upgrade -y \
      	&& apt-get install -y mono-runtime=$DEBIAN_MONO_VERSION mono-mcs=$DEBIAN_MONO_VERSION mono-xbuild=$DEBIAN_MONO_VERSION mono-devel=$DEBIAN_MONO_VERSION ca-certificates-mono \
      	&& apt-get -y autoremove \
      	&& apt-get -y clean \
      	&& rm -rf /var/lib/apt/lists/*
      

      Final­ly, .NET Core 1.0.1 and the pre­view tool­ing (dotnet-dev-1.0.0-preview2-003131). This block brings in the tool­ing:

      RUN     apt-get update \
              && apt-get install -y apt-transport-https \
              && echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet/ trusty main" > /etc/apt/sources.list.d/dotnetdev.list \
              && apt-key adv --keyserver apt-mo.trafficmanager.net --recv-keys 417A0893 \
      	&& apt-get update \
      	&& apt-get install -y dotnet-dev-1.0.0-preview2-003131 \
      	&& apt-get -y autoremove \
      	&& apt-get -y clean \
      	&& rm -rf /var/lib/apt/lists/*
      

      For dock­er ver­sions ear­li­er than 1.11.0, you’d also need an addi­tion­al envi­ron­ment set­ting to pre­vent this bug:

      ENV LTTNG_UST_REGISTER_TIMEOUT 0
      

      In order to pre­vent the “one-time” warmup of the dotnet CLI tool, add

      ENV NUGET_XMLDOC_MODE skip
      RUN mkdir warmup \
          && cd warmup \
          && dotnet new \
          && cd .. \
          && rm -rf warmup
      

      The final and miss­ing clue is this com­ment on GitHub: When build­ing net4xx (i.e. .NET Frame­work tar­gets as opposed to .NET Core), you will run into pret­ty nasty errors stat­ing that System.Native.dll couldn’t be found. Sim­ply patch in a sym­link to the file already installed by .NET Core and you’ll be fine:

      RUN ln -s /usr/share/dotnet/shared/Microsoft.NETCore.App/1.0.1/System.Native.so /usr/lib/libSystem.Native.so && \
          ldconfig
      

      With that, you’re done. Grab the code here or pull the image from the Dock­er Hub using

      docker pull sunside/dotnet:1.0.0-preview2-003131
      
      September 14th, 2016 GMT +1 von
      Markus
      2016-09-14T16:38:07+01:00 2016-09-14T16:44:20+01:00 · 0 Kommentare
      docker Mono
      .NET ASP.NET DNX Core
      • Building Caffe on Windows using Visual Studio 201…3

        Note that now that BVLC’s caffe repos­i­to­ry direct­ly sup­ports com­pi­la­tion on Win­dows, this guide has become obso­lete.

        When attempt­ing to check out Caffe after some wast­ed hours of get­ting Ten­sor­Flow to run on Win­dows (which sort-of works using Bash for Win­dows), I gave Caffe a try. How­ev­er, the last time I tried to get a huge sys­tem of nest­ed depen­den­cies using CMake to work on Win­dows, things only got worse with every addi­tion­al project. For Caffe, you’d need Boost, OpenCV, HDF and pro­to­buf as well as some Google log­ging and com­mand-line argu­ment things amongst oth­er stuff — and boy, make sure you got your link­ing, thread­ing and run­time right, and don’t even think about mix­ing dif­fer­ent C++ or Boost fla­vors.

        So there’s this Win­dows fork of Caffe man­aged by Microsoft which appar­ent­ly only requires you to con­fig­ure the CommonSettings.props file to your lik­ing and then com­pile. The nice part is, all ref­er­ences are pulled using NuGet. The bad part is, the pack­ages are all MSVC 1800, i.e. Visu­al Stu­dio 2013. You’ll be able to find new­er vari­ants of Boost, but that’s about it.

        If you’re real­ly try­ing to use Visu­al Stu­dio 2015, fix the nuget.config to have the repos­i­to­ry path fixed like described in this Stack­Over­flow answer:

        <?xml version="1.0" encoding="utf-8"?>
        <configuration>
          <packageSources>
            <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
          </packageSources>
          <add key="repositoryPath" value="..\..\NugetPackages" />
        </configuration>
        

        Also note that the path is most like­ly out­side your build tree … but that’s how it is pro­vid­ed by the main­tain­er.
        I wast­ed anoth­er day try­ing to get Caffe to work in Visu­al Stu­dio 2015 by select­ing the 2013 toolk­it but, in the end, it came down to the fol­low­ing error:

        NuGet error: unknown command 'overlay' 
        

        This overlay stuff appar­ent­ly is some NuGet 2 mag­ic that didn’t sur­vive the dark ages, so it won’t work with NuGet 3, which I have in my path and which is also used inter­nal­ly by VS 2015.
        There are a cou­ple of ques­tions regard­ing that error, like this one on the OpenCV Answers site, issues on GitHub (with half-bro­ken answers since the CoApp tool­ing doesn’t real­ly work exist any­more), etc., but there’s no obvi­ous solu­tion — at least if you’re using a mod­ern Win­dows devel­op­ment envi­ron­ment — that is, one that’s using NuGet 3 instead of NuGet 2.6.

        You can fix most of the prob­lems by just upgrad­ing OpenCV 2 to OpenCV 3. For that, kick out the old NuGet pack­ages and ref­er­ence the opencvde­fault one as shown in this video. But even if you do that, it’ll fail on the glog 0.3.3 NuGet pack­age which still uses over­lays.

        As it turns out though, the NuGet pack­age for glog 0.3.3 already con­tains a NuGet bina­ry at glog.0.3.3.0/build/native/private/nuget.exe, but since it’s not in the path, it won’t use it. Copy that to the package’s root (where NuGet-Overlay.cmd can be found and you’re set.

        For the rest, make sure you’re using Python 2.7 though, as the Boost libraries are requir­ing that; also install NumPy.
        Using e.g. Ana­con­da Python, you’d want

        conda create -n caffe python=2.7 numpy
        

        Which will leave you with the task to find python27_d.lib … or just build Release.

        September 1st, 2016 GMT +1 von
        Markus
        2016-09-1T12:46:36+01:00 2016-12-12T16:03:10+01:00 · 0 Kommentare
        tensorflow caffe Visual Studio 2013 Visual Studio 2015
        Machine Learning Caffe
        • Rust: adding arbitrary things

          I just start­ed learn­ing Rust some days ago and, com­ing from a C/C++/C# back­ground, imme­di­ate­ly stubbed my toe on the type sys­tem. The notion of traits, how­ev­er, is some­thing I real­ly like and allows for a stunt that is impos­si­ble in C# and ugly in C++: adding things, where by things I mean all the things.

          Add all the things!

          The key is to con­strain a gener­ic type para­me­ter with the Add<T> trait. In this exam­ple, I’m con­strain­ing a gener­ic type T1 to be Add<T2>, that is, to be able to add a T2 to itself. The result of such an oper­a­tion is obvi­ous­ly gener­ic as well, <T1 as Add<T2>>::Output (with Output being the type), allow­ing for the fol­low­ing code:

          fn add<T1, T2>(a:T1, b:T2) -> <T1 as Add<T2>>::Output
              where T1: Add<T2>
          {
              a+b
          }
          

          While this func­tion does noth­ing more than adding two val­ues of arbi­trary types (try that in C# with prim­i­tive types), the under­ly­ing mech­a­nism allows for inter­est­ing oper­a­tions such as vec­tor-matrix mul­ti­pli­ca­tion with­out hav­ing to resort to a con­crete type. A Complex would work as well as a prim­i­tive f32 (i.e. float), f64 (i.e. double), etc.
          You can do this in C++, but instead of hav­ing the com­pil­er check the traits (like rustc does), you rather have to hope that some­one imple­ment­ed that spe­cif­ic oper­a­tor over­load or else you’d be in tem­plate error mes­sage hell.

          Dezember 10th, 2015 GMT +1 von
          Markus
          2015-12-10T22:01:56+01:00 2015-12-10T22:05:00+01:00 · 0 Kommentare
          Generics
          Rust
          • “Compiler crashed with code 1” on Mono

            Update:
            I opened a bug tick­et for the described issue and it got fixed with­in the week.

            Orig­i­nal post:
            At work we recent­ly stum­bled across an inter­est­ing prob­lem: While com­pi­la­tion of our C# 6 code base would work fine on Win­dows, a guy that works on OSX using Xam­arin Stu­dio sud­den­ly was unable to com­pile the code, because “Error: Com­pil­er crashed with code 1”. No line num­ber, no noth­ing, only that.

            After a run through git bisect we even­tu­al­ly were able to track down the com­mit where I found the error to lie with­in an await hap­pen­ing in a string inter­po­la­tion. Sad­ly, this prob­lem was intro­duced by sim­ply (and auto­mat­i­cal­ly) refac­tor­ing all occur­rences of String.Format() in the file.

            I was able to repro­duce the prob­lem with the fol­low­ing sim­ple code:

            private async Task<int> Foo() 
            {
                await Task.Delay(1);
                return 42;
            }
            
            private async Task Bar()
            {
                Console.WriteLine($"Something {await Foo()}");
            }
            

            Appar­ent­ly, the mono com­pil­er doesn’t like that too much. The solu­tion to this is sim­ple: Don’t await with­in the inter­po­lat­ed string.
            Instead, do it out­side:

            private async Task Bar()
            {
                var foo = await Foo();
                Console.WriteLine($"Something {foo}");
            }
            

            And that’s that.

            Dezember 4th, 2015 GMT +1 von
            Markus
            2015-12-4T13:29:31+01:00 2015-12-10T21:34:40+01:00 · 0 Kommentare
            Bug Mono async/await
            .NET
            • Fun with ASP.NET 5 beta7: Bliss, Build errors, Dockerfiles and Reverse Proxies

              I was nev­er a ASP.NET devel­op­er, but since self-host­ing on Lin­ux only meant trou­ble, I gave ASP.NET vNext a try. At first, the whole DNX and .NET Core thing hit me like a ham­mer. A big one. Wield­ing a jack­ham­mer. After work­ing with it for a cou­ple of days now though, I’m actu­al­ly more than excit­ed — it’s almost heresy. With all the log­ging, con­fig­u­ra­tion ser­vices (Microsoft.Framework.Configuration!), devel­op­er secrets, host-inte­grat­ed depen­den­cy injec­tion includ­ed by design — not to for­get the Lin­ux sup­port — there’s absolute­ly no way I’ll ever go back to .NET once DNX is sta­ble.

              That said, here are some things I stum­bled over:

              • If you just installed Visu­al Stu­dio 2015 Com­mu­ni­ty and ASP.NET is still beta, make sure to install the newest beta inte­gra­tion. Last time I checked I was two ver­sions behind and things change rapid­ly at the moment.
              • When div­ing into this DNX (“Class Library (Pack­age)”, “Con­sole Appli­ca­tion (Pack­age)”, ASP.NET 5 web project) thing, if you don’t explic­it­ly need .NET Core sup­port, kick the dnxcore50 frame­work out of the projects.json. That reduces pain time to a min­i­mum, when oth­er­wise you’d be search­ing for the cause of one gazil­lion build errors that should not be there.
              • When using the offi­cial (and sweet) microsoft/aspnet Dockerfile, know that the exam­ples are tai­lored for sin­gle-project solu­tions. Below is how I did it in the end.
              • At least as per beta 7, the dnu restore in the docker build process takes ages. This has like­ly some­thing to do with mono and — as per this bug report — there’s a quick fix for it: Add ENV MONO_THREADS_PER_CPU 2000 to your Dockerfile and see the world with new eyes.
              • I also had to write a mid­dle­ware for MVC 6 to sup­port X-Forwarded-Proto and the offi­cial RFC 7239 Forwarded head­ers, more below.

              First of all, I had my devel­op­ment site run­ning local­ly in Visu­al Stu­dio, avail­able to the sub­net through a local nginx reverse proxy which I would use to dis­patch to any of my devel­op­ment web­sites. In this case, the .../aspnet route would point to my self-host­ed appli­ca­tion. That nginx, in turn, was behind anoth­er nginx, lis­ten­ing to the https://myhost/testing route on the actu­al web­serv­er. Sad­ly, this base path of /testing/aspnet was total­ly trip­ping up ASP.NET which assumed a base path of /, also the pro­to­col was not rec­og­nized. So I added this con­fig­u­ra­tion to my local nginx:

              upstream local_aspnet {
                  server localhost:9000;
              }
              
              server {
                  listen       80;
                  server_name  myhost localhost;
              
                  location /aspnet {
                      rewrite /testing/aspnet(.*) $1  break;
              
                      # Handled within ASP.NET
                      proxy_set_header  X-Base-Path /testing/aspnet;
              
                      proxy_set_header  X-Real-IP  $remote_addr;
                      proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
                      proxy_set_header  X-Forwarded-Proto "https";
              
                      proxy_pass http://local_aspnet/;
              
                      proxy_redirect off;
                      proxy_set_header HOST $host;
                      proxy_buffering off;
                      break;
                  }
              }
              

              And imple­ment­ed the fol­low­ing in C#:

              public static void UseReverseProxyProtocolRecognition(
                                             [NotNull] this IApplicationBuilder app)
              {
                  app.Use(next => context =>
                  {
                      var request = context.Request;
                      var headers = request.Headers;
              
                      if (!string.IsNullOrWhiteSpace(headers["X-Base-Path"]))
                      {
                          request.PathBase = headers["X-Base-Path"];
                      }
              
                      if (string.Equals(context.Request.Headers["X-Forwarded-Proto"], 
                                        Uri.UriSchemeHttps, 
                                        StringComparison.OrdinalIgnoreCase))
                      {
                          request.Scheme = Uri.UriSchemeHttps;
                      }
                      else if (!string.IsNullOrWhiteSpace(headers["Forwarded"]))
                      {
                          // http://tools.ietf.org/html/rfc7239
                          var match = Regex.Match(headers["Forwarded"], 
                                                  @"proto=(?<proto>https?)");
                          if (match.Success)
                          {
                              request.Scheme = match.Groups["proto"].Value;
                          }
                      }
                      return next(context);
                  });
              }
              

              which allowed me to sim­ply do:

              public void Configure(IApplicationBuilder app, IApplicationEnvironment env,
                                    ILoggerFactory loggerfactory)
              {
                  // ...
                  app.UseReverseProxyProtocolRecognition();
                  // ...
              }
              

              As for the Dockerfile, since I was using mul­ti­ple projects in one solu­tion, I had to cheat a lit­tle. This file works by copy­ing the project files into the image, then run­ning dnu restore indi­vid­u­al­ly for each DNX project, then adding the whole sources. This — when putting the least mod­i­fied project first — allows for caching as much as pos­si­ble when rebuild­ing the image, while still allow­ing for cross-project depen­den­cies. Also note the use of MONO_THREADS_PER_CPU which real­ly is a life-saver here.

              FROM microsoft/aspnet
              
              ENV MONO_THREADS_PER_CPU 2000
              ENV STARTUP_PROJECT src/Startup.Project
              
              COPY NuGet.Config /app/
              COPY global.json /app/
              
              COPY src/Startup.Project/project.json /app/src/Startup.Project/
              COPY src/Second.Project/project.json  /app/src/Second.Project.Models/
              COPY src/Third.Project/project.json   /app/src/Third.Project/
              
              WORKDIR /app/src/Startup.Project
              RUN ["dnu", "restore"]
              
              WORKDIR /app/src/Second.Project
              RUN ["dnu", "restore"]
              
              WORKDIR app/src/Third.Project
              RUN ["dnu", "restore"]
              
              COPY . /app
              WORKDIR /app/$STARTUP_PROJECT
              
              EXPOSE 5004
              ENTRYPOINT ["dnx", "kestrel"]
              

              If you’re at it, check out the Dock­er for Win­dows toolk­it which amaz­ing­ly sucks less than it did some months ago.
              Also have fun and cof­fee. You know I do.

              September 8th, 2015 GMT +1 von
              Markus
              2015-09-8T19:59:20+01:00 2015-09-8T19:59:20+01:00 · 0 Kommentare
              Windows Linux docker .NET vNext nginx
              .NET ASP.NET DNX
    1. « newer
    2. 1
    3. 2
    4. 3
    5. 4
    6. 5
    7. 6
    8. 7
    9. 8
    10. 9
    11. older »
    • Kategorien

      • .NET
        • ASP.NET
        • Core
        • DNX
      • Allgemein
      • Android
      • Data Science
      • Embedded
      • FPGA
      • Humor
      • Image Processing
      • Kalman Filter
      • Machine Learning
        • Caffe
        • Hidden Markov Models
        • ML Summarized
        • Neural Networks
        • TensorFlow
      • Mapping
      • MATLAB
      • Robotik
      • Rust
      • Signal Processing
      • Tutorial
      • Version Control
    • Neueste Beiträge

      • Summarized: The E-Dimension — Why Machine Learning Doesn’t Work Well for Some Problems?
      • Use your conda environment in Jupyter Notebooks
      • Building OpenCV for Anaconda Python 3
      • Using TensorFlow’s Supervisor with TensorBoard summary groups
      • Getting an image into and out of TensorFlow
    • Kategorien

      .NET Allgemein Android ASP.NET Caffe Core Data Science DNX Embedded FPGA Hidden Markov Models Humor Image Processing Kalman Filter Machine Learning Mapping MATLAB ML Summarized Neural Networks Robotik Rust Signal Processing TensorFlow Tutorial Version Control
    • Tags

      .NET Accelerometer Anaconda Bitmap Bug Canvas CLR docker FPGA FRDM-KL25Z FRDM-KL26Z Freescale git Gyroscope Integration Drift Intent J-Link Linear Programming Linux Magnetometer Matlab Mono Naismith OpenCV Open Intents OpenSDA Optimization Pipistrello Player/Stage PWM Python Sensor Fusion Simulink Spartan 6 svn tensorflow Tilt Compensation TRIAD ubuntu Windows Xilinx Xilinx SDK ZedBoard ZYBO Zynq
    • Letzte Kommetare

      • Lecke Mio bei Frequency-variable PWM generator in Simulink
      • Vaibhav bei Use your conda environment in Jupyter Notebooks
      • newbee bei Frequency-variable PWM generator in Simulink
      • Markus bei Using TensorFlow’s Supervisor with TensorBoard summary groups
      • Toke bei Using TensorFlow’s Supervisor with TensorBoard summary groups
    • Blog durchsuchen

    • Januar 2021
      M D M D F S S
      « Mrz    
       123
      45678910
      11121314151617
      18192021222324
      25262728293031
    • Self

      • Find me on GitHub
      • Google+
      • Me on Stack­Ex­change
      • Ye olde blog
    • Meta

      • Anmelden
      • Beitrags-Feed (RSS)
      • Kommentare als RSS
      • WordPress.org
    (Generiert in 0,454 Sekunden)

    Zurück nach oben.