Commit 07b605e6 authored by Elias2049's avatar Elias2049
Browse files

Merge branch 'master' of https://gitlab.ocamlpro.com/OCamlPro/www into CssElias

parents e382d7f8 d45ccbf8
title=Optimisation du stockage dans Tezos : une branche de test sur Gitlab
authors=Fabrice Le Fessant
date=2019-02-04
category=Blockchains
tags=tezos,optimisation,fr
Ce troisième article consacré à l’amélioration du stockage dans Tezos fait suite à l’annonce de la mise à disposition d’une image docker pour
les beta testeurs souhaitant essayer notre système de stockage et garbage collector.
Voir [Improving Tezos Storage : Gitlab branch for testers](/2019/02/04/improving-tezos-storage-gitlab-branch-for-testers/)
......@@ -21,3 +21,72 @@ migrate the database back to Irmin (and terminate the node
afterwards).
Enjoy and send us feedback !!
# Comments
AppaDude (10 February 2019 at 15 h 12 min):
> I must be missing something. I compiled and issued the required rpc trigger:
>
> /storage/context/gc with the command
>
> ~/tezos/tezos-client rpc get /storage/context/gc
> But I just got an empty JSON response of {} and the size of the .tezos-node folder is unchanged. Any advice is much appreciated.
> Thank you!
Fabrice Le Fessant (10 February 2019 at 15 h 47 min):
> By default, garbage collection will keep 9 cycles of blocks (~36000 blocks). If you have fewer blocks, or if you are using Irontez on a former Tezos database, and fewer than 9 cycles have been stored in Irontez, nothing will happen. If you want to force a garbage collection, you should tell Irontez to keep fewer block (but more than 100, that’s the minimum that we enforce):
>
> ~/tezos/tezos-client rpc get ‘/storage/context/gc?keep=120’
>
> should trigger a GC if the node has been running on Irontez for at least 2 hours.
AppaDude (10 February 2019 at 16 h 04 min):
> I think it did work. I was confused because the total disk space for the .tezos-node folder remained unchanged. Upon closer inspection, I see these contents and sizes:
>
> These are the contents of .tezos-node, can I safely delete context.backup?
>
> 4.0K config.json
> 269M context
> 75G context.backup
> 4.0K identity.json
> 4.0K lock
> 1.4M peers.json
> 5.4G store
> 4.0K version.json
> Is it safe to delete context.backup if I do not plan to revert? (/storage/context/revert)
Fabrice Le Fessant (10 February 2019 at 20 h 51 min):
> Yes, normally. Don’t forget it is still under beta-testing…
>
> Note that `/storage/context/revert` works even if you remove `context.backup`.
Jack (23 February 2019 at 0 h 24 min):
> Have there been any issues reported with missing endorsements or missing bakings with this patch? We have been using this gc version (https://gitlab.com/tezos/tezos/merge_requests/720) for the past month and ever since we switched we have been missing endorsements and missing bakings. The disk space savings is amazing, but if we keep missing ends/bakes, it’s going to hurt our reputation as a baking service.
Fabrice Le Fessant (23 February 2019 at 6 h 58 min):
> Hi,
>
> I am not sure what you are asking for. Are you using our version (https://gitlab.com/tzscan/tezos/commits/mainnet-staging-irontez), or the one on the Tezos repository ? Our version is very different, so if you are using the other one, you should contact them directly on the merge request. On our version, we got a report last week, and the branch has been fixed immediately (but not yet the docker images, should be done in the next days).
Jack (25 February 2019 at 15 h 53 min):
> I was using the 720MR and experiencing issues with baking/endorsing. I understand that 720MR and IronTez are different. I was simply asking if your version has had any reports of baking/endorsing troubles.
Jack (25 February 2019 at 15 h 51 min):
> Is there no way to convert a “standard node” to IronTez? I was running the official tezos-node, and my datadir is around 90G. I compiled IronTez and started it up on that same dir, then ran `rpc get /storage/context/gc` and nothing is happening. I thought this was supposed to convert my datadir to irontez? If not, what is the RPC to do this? Or must I start from scratch to be 100% irontez?
Fabrice Le Fessant (25 February 2019 at 16 h 24 min):
> There are two ways to get a full Irontez DB:
> - Start a node from scratch and wait for one or two days…
> - Use an existing node, run Irontez on it for 2 hours, and then call `rpc get /storage/context/gc?keep=100` . 100 is the number of blocks to be kept. After 2 hours, the last 120 blocks should be stored in the IronTez DB, so the old DB will not be used anymore. Note that Irontez will not delete the old DB, just rename it. You should go there and remove the file to recover the disk space.
Jack (27 February 2019 at 1 h 24 min):
> Where do we send feedback/get help? Email? Slack? Reddit?
Banjo E. (3 March 2019 at 2 h 40 min):
> There is a major problem for bakers who want to use the irontez branch. After garbage collection, the baker application will not start because the baker requests a rpc call for the genesis block information. That genesis block information is gone after the garbage collection. Please address this isssue soon. Thank you!
Fabrice Le Fessant (6 March 2019 at 21 h 44 min):
> I pushed a new branch with a tentative fix: https://gitlab.com/tzscan/tezos/tree/mainnet-staging-irontez-fix-genesis . Unfortunately, I could not test it (I am far away from work for two weeks), so feedback is really welcome, before pushing in the irontez branch.
title=Release de Techelson, moteur de tests pour Michelson et Liquidity
authors=Adrien Champion
date=2019-03-05
category=Blockchains
tags=techelson,fr
Nous sommes fiers d’annoncer la première release de Techelson, moteur d’exécution de tests pour Michelson. Les programmeurs Liquidity peuvent également l’utiliser.
Voir [Techelson, a test execution engine for Michelson](/2019/03/05/techelson-a-test-execution-engine-for-michelson/).
title=Announcing Liquidity version 1.0
authors=Alain Mebsout=
authors=Alain Mebsout
date=2019-03-08
category=Blockchains
tags=liquidity
......
......@@ -99,3 +99,8 @@ node.
> Don’t hesitate to contact us if you want to deploy a blockchain with IronTez, or for more information !
# Comments
Kristen (3 May 2019 at 0 h 30 min):
> I really wanted to keep using IronTez but I ran into bugs that have not yet been fixed, the code is out of date with upstream, and there is no real avenue for support/assistance other than email.
title=Résultats de la SMT-Comp 2019 pour Alt-Ergo
authors=Albin Coquereau
date=2019-07-10
category=Formal Methods
tags=alt-ergo,fr
Les résultats de la compétition SMT-COMP 2019 ont été publiés au whorkshop  SMT de la [22e conférence SAT](https://smt2019.galois.com/). Nous étions fiers d’y participer pour la deuxième année consécutive, surtout depuis qu’Alt-Ergo [prend en charge](/2019/02/11/whats-new-for-alt-ergo-in-2018-here-is-a-recap/) le standard [SMT-LIB 2](https://smtlib.cs.uiowa.edu/).
> Alt-Ergo est un SAT solveur open-source maintenu et distribué par OCamlPro, et financé entre autres grâce à plusieurs projets de R&D collaborative (BWare, SOPRANO, Vocal, LChip).
> Si vous êtes un utilisateur d’Alt-Ergo, songez à rejoindre le [Club des Utilisateurs d’Alt-Ergo](https://alt-ergo.ocamlpro.com/#club)! L’histoire de ce logiciel remonte à 2006, où il est né de recherches académiques conjointes entre Inria et le CNRS dans le laboratoire du LRI. Il est depuis septembre 2013 maintenu, développé  et distribué par OCamlPro (voir l’historique des [versions passées](https://alt-ergo.ocamlpro.com/#releases)).
> *Si vous êtes curieux des activités d’OCamlPro dans le domaine des méthodes formelles, vous pouvez lire le court témoignage d’un [client heureux](http://ocamlpro.com/clients-partners/#mitsubishi-merce).*
Voir [](/2019/07/09/alt-ergo-participation-to-the-smt-comp-2019/)
title=Release d’opam 2.0.5
authors=Raja Boujbel,Louis Gesbert
date=2019-07-23
category=Tooling
tags=opam,fr
Nous sommes fiers d’annoncer la release (mineure) d’ [opam 2.0.5](https://github.com/ocaml/opam/releases/tag/2.0.5). Cette nouvelle version contient des mises à jours de build et correctifs.
> [Plus d’information](/2019/07/11/opam-2-0-5-release/)
......@@ -94,3 +94,14 @@ These improvements are still very much a work in progress. We have not reached t
This does not mean there are no news to enjoy before our efforts show on the mainstream compiler! While working on Flambda 2.0, we did deploy a number of patches on the compiler both before and after the Flambda stage. We proposed all the changes independant enough to be proposed on their own. Some of these fixes have been merged already. Others are still under discussion and some, like the recursive values patch mentioned above, are still waiting for cleanup or documentation before submission.
# Comments
Jon Harrop (30 August 2019 at 20 h 11 min):
> What is the status of multicore OCaml?
Vincent Laviron (2 September 2019 at 16 h 22 min):
> OCamlPro is not working on multicore OCaml. It is still being worked on elsewhere, with efforts concentrated around OCaml Labs, but I don’t have more information than what is publicly available. All of the work we described here is not expected to interfere with multicore.
Lindsay (25 September 2020 at 20 h 20 min):
> Thanks for your continued work on the compiler and tooling! Am curious if there is any news regarding the item “Separate compilation of recursive modules”.
title=Mise à jour des Cheat Sheets : OCaml Language et OCaml Standard Library
authors=Thomas Blanc
date=2019-09-13
category=OCaml
tags=ocaml,documentation,cheat-sheets,fr
Les mémentos (cheat-sheets) OCaml lang et OCaml stdlib partagés par OCamlPro en 2011 ont été mis à jour pour OCaml 4.08.
- [Le langage OCaml](https://ocamlpro.github.io/ocaml-cheat-sheets/ocaml-lang.pdf)
- - [OCaml Standard Library](https://ocamlpro.github.io/ocaml-cheat-sheets/ocaml-stdlib.pdf)
Si vous souhaitez contribuer des améliorations: [sources sur GitHub](https://github.com/OCamlPro/ocaml-cheat-sheets).
En savoir plus : [Updated Cheat Sheets: OCaml Language and OCaml Standard Library](/2019/09/13/updated-cheat-sheets-ocaml-language-and-ocaml-standard-library/)
......@@ -141,3 +141,24 @@ And here we are with 4.08, in the present day! We can now put exceptions under o
We did not add 4.09 to this journey to the past, as this release is still solidly in the *now* at the time of this blogpost. Rest assured, we will see much more awesome features in OCaml in the future! In the meantime, we are working on updating more cheat sheets: keep posted!
# Comments
Micheal Bacarella (23 September 2019 at 18 h 17 min):
> For a blog-post from a company called OCaml PRO this seems like a rather tone-deaf PR action.
>
> I wanted to read this and get hyped but instead I’m disappointed and I continue to feel like a chump advocating for this language.
>
> Why? Because this is a rather underwhelming summary of *8 years* of language activity. Perhaps you guys didn’t intend for this to hit the front of Hacker News, and maybe this stuff is really exciting to programming language PhDs, but I don’t see how the average business OCaml developer would relate to many of these changes at all. It makes OCaml (still!) seem like an out-of-touch academic language where the major complaints about the language are ignored (multicore, Windows support, programming-in-the-large, debugging) while ivory tower people fiddle with really nailing type-based selection in GADTs.
>
> I expect INRIA not to care about the business community but aren’t you guys called OCaml PRO? I thought you *liked* money.
>
> You clearly just intended this to be an interesting summary of changes to your cheatsheet but it’s turned into a PR release for the language and leaves normals with the continued impression that this language is a joke.
Thomas Blanc (24 September 2019 at 14 h 57 min):
> Yes, latency can be frustrating even in the OCaml realm. Thanks for your comment, it is nice to see people caring about it and trying to remedy through contributions or comments.
>
> Note that we only posted on discuss.ocaml.org expecting to get one or two comments. The reason for this post was that while updating the CS we were surprised to see how much the language had changed and decided to write about it.
>
> You do raise some good points though. We did work on a full windows support back in the day. The project was discontinued because nobody was willing to buy it. We also worked on memory profiling for the debugging of memory leaks (before other alternatives existed). We did not maintain it because the project had no money input. I personally worked on compile-time detection of uncaught exception until the public funding of that project ran out. We also had a proposal for namespaces in the language that would have facilitated programming-in-the-large (no funding) and worked on multicore (funding for one man for one year).
title=Formations OCaml par OCamlPro : 5-6 et 7-8 novembre 2019
authors=OCamlPro
date=2019-09-25
category=Trainings
tags=documentation,report,training,fr,formation
![](/blog/assets/img/trainings_2019.png)
OCamlPro lance un cycle de formations régulières à OCaml, en français, dans ses locaux parisiens (métro Alésia). La première session aura lieu début novembre 2019, avec 2 formations:
- Formation débutant : [passer à OCaml](/fr/formation-passer-a-ocaml/) (5-6 novembre)
- Formation expert : [approfondir sa maîtrise du langage](/fr/formation-expert-ocaml/) (7-8 novembre).
La formation expert sera l’occasion pour des programmeurs OCaml ayant
déjà une certaine expérience de mieux comprendre les possibilités
avancées du typage (objets, GADTs), de découvrir en détail le
fonctionnement du GC et d’écrire du code optimisable par le compilateur.
Ces formations sont aussi une occasion de venir discuter avec les
lead développeurs et contributeurs d’OPAM et Flambda chez OCamlPro.
> Des formations en anglais peuvent aussi être organisées sur demande à contact@ocamlpro.com
title=OCamlPro’s compiler team work update
authors=Vincent Laviron
date=2019-08-30
category=OCaml
tags=flambda2,compiler
![](/blog/assets/img/picture_cpu_compiler.jpeg)
Nous sommes heureux de présenter certains travaux en cours sur le compilateur OCaml, travaux menés en étroite collaboration avec notre partenaire et client Janestreet.
Un travail conséquent a été fait pour aboutir à un nouveau framework d’optimisation du compilateur, appelé Flambda2, dont nous espérons qu’il corrigera certains défauts apparus dans Flambda. En parallèle, l’équipe a mené à bien certaines améliorations immédiates sur Flambda, ainsi que des modifications du compilateur qui seront utiles pour Flambda2.
Voir (en anglais) : [OCamlPro’s compiler team work update](/2019/08/30/ocamlpros-compiler-team-work-update/)
title=2019 chez OCamlPro
authors=OCamlPro
date=2020-02-04
category=OCamlPro
tags=compiler,cheat sheet,OCamlPro,opam,Rust,Try-OCaml,OCaml,Alt-Ergo,blockchains,Flambda2,fr
![2019 at OCamlPro](assets/img/logo_ocp_2019.png)
OCamlPro a pour ambition d’aider les industriels dans leur adoption du langage OCaml et des méthodes formelles. L’entreprise est passée d’1 à 21 personnes et est restée fidèle à cet objectif. L’année 2019 chez OCamlPro a été très animée, et le nombre de réalisations impressionnant,
d’abord dans le monde OCaml (flambda2 & optimisations du compilateur, opam 2, notre interface Rust pour memprof, des outils comme
tryOCaml, ocp-indent, et le soutien à la OCaml Software Foundation), et dans le monde des méthodes formelles (nouvelles versions de notre
solveur SMT Alt-Ergo, lancement du Club des utilisateurs Alt-Ergo,lancement du langage Love, etc.)
[Lire la suite (en anglais)](/2020/02/04/2019-at-ocamlpro/)
......@@ -2,7 +2,7 @@ title=Réunion annuelle du Club des utilisateurs d’Alt-Ergo
authors=Aurore Dromby
date=2020-03-03
category=Formal Methods
tags=alt-ergo
tags=alt-ergo,fr
![Alt-Ergo meeting](assets/img/altergo-meeting.jpeg)
![Logo Alt-Ergo](../assets/img/logo_altergo.png)
......@@ -23,4 +23,4 @@ Nos membres sont particulièrement intéressés par les points suivants :
– L’amélioration du support de l’arithmétique non linéaire dans Alt-Ergo
Ces fonctionnalités sont maintenant nos principales priorités. Pour suivre nos avancement et les nouveautés, n’hésitez pas à lire nos [articles](category/formal_methods) sur ce blog.
\ No newline at end of file
Ces fonctionnalités sont maintenant nos principales priorités. Pour suivre nos avancement et les nouveautés, n’hésitez pas à lire nos [articles](category/formal_methods) sur ce blog.
title=Le nouveau GC d’OCaml 4.10 : premier aperçu de la stratégie best-fit
authors=Thomas Blanc
date=2020-03-23
category=OCaml
tags=best fit,fr,gc,ocaml
![An in-depth Look at OCaml’s new "Best-fit" Garbage Collector Strategy](assets/img/logo_round_ocaml_search.png)](/blog/2020_03_23_in_depth_look_at_best_fit_gc)
Le GC d’OCaml oeuvre discrètement à l’efficacité de vos allocations mémoire. Tel un héros de l’ombre, il reste méconnu de la plupart des
hackers OCaml. Avec l’arrivée d’OCaml 4.10, il s’enrichit d’une nouvelle stratégie apparue dans le [changelog](https://ocaml.org/releases/4.10.0.html#Changes), signée de Damien Doligez.
Dans cet article nous commençons à explorer la nouvelle stratégie baptisée *best-fit *du nouveau Glaneur de Cellules dans OCaml 4.10.
> En savoir plus : [article en anglais](/2020/03/23/ocaml-new-best-fit-garbage-collector/).
......@@ -251,4 +251,24 @@ The different strategies are:
Remember that whatever works best for you, it’s still better than having to `malloc` and `free` by hand. Happy allocating!
# Comments
gasche (23 March 2020 at 17 h 50 min):
> What about higher overhead values than 120, like 140, 160, 180 and 200?
Thomas Blanc (23 March 2020 at 18 h 17 min):
> Because 100 was the overhead value Leo advised in the PR discussion I decided to put it in the results. As 120 got the same maximum heap size as next-fit I found it worth putting it in. Higher overhead values lead to faster execution time but a bigger heap.
>
> I don’t have my numbers at hand right now. You’re probably right that they are relevant (to you and Damien at least) but I didn’t want to have a huge table at the end of the post.
nbbb (24 March 2020 at 11 h 18 min):
> Higher values would allow us to see if best-fit can reproduce the performance characteristics of next-fit, for some value of the overhead.
nbbb (24 March 2020 at 16 h 51 min):
> I just realized that 120 already has a heap as bit as next-fit — so best-fit can’t get as good as next-fit in this example, and higher values of the overhead are not quite as informative. Should have read more closely the first time.
Thomas Blanc (24 March 2020 at 16 h 55 min):
> Sorry that it wasn’t as clear as it could be.
>
> Note that opam and dose are in the best-case scenario of best-fit. Your own code would probably produce a different result and I encourage you to test it and communicate about it.
......@@ -2,7 +2,7 @@ title=A Solidity parser in OCaml with Menhir
authors=David Declerck
date=2020-05-19
category=Blockchains
tags=blockains,solidity,parser
tags=blockchains,solidity,parser
<p align="center" >
<a href="/blog/2020_05_19_ocaml_solidity_parser_with_menhir">
......
......@@ -2,7 +2,7 @@ title=Tutoriel Format
authors=OCamlPro
date=2020-06-01
category=Trainings
tags=tutoriel,format,documentation
tags=tutoriel,format,documentation,fr
*Article écrit par Mattias.*
......@@ -659,7 +659,7 @@ Et l’affichage dans le terminal sera bien celui voulu :
Si le programme doit être affiché dans un terminal non ANSI il suffit simplement d’enlever la ligne `add_ansi_marking std_formatter;` :
![Exemple de marquage avec la gestion des tags sémantiques par Format dans un terminal ANSI](ansi-color-try-stag.png)
![Exemple de marquage avec la gestion des tags sémantiques par Format dans un terminal ANSI](/blog/assets/img/ansi-color-try-stag.png)
On pourrait aussi faire en sorte que notre texte puisse être envoyé vers un document HTML.
......
......@@ -2,7 +2,7 @@ title=A Dune Love story: From Liquidity to Love
authors=Steven De Oliveira
date=2020-06-09
category=Blockchains
tags=blockchain,smart contracts,love,liquidity
tags=blockchains,smart contracts,love,liquidity
<div align="center">
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment