Translate

The nice thing about using `get` and `set` across threads like this is that it will always produce the same result every time you hit run. Go on, try it. See if you get the following in your log:
SourceTranslationState
1012
print get[:intensity] #=> prints 3000
print get[:intensiteit] #=> print 3000
1013
Notice that calls to `get` can return information that was `set` in a previous run. Once a piece of information has been `set` it is available until either the information is overridden (just like we clobbered the `:intensity` value of `1000` to `3000` above) or Sonic Pi is closed.
Merk op dat aanroepen van `get` informatie kunnen teruggeven die was ge`set` in de vorige uitvoering. Wanneer een stuk informatie is ge`set` is het beschikbaar totdat of de informatie is overschreven (net als de aanpassing van `:intensiteit` van de waarde `1000` naar `3000` hierboven) of Sonic Pi is afgesloten.
1014
Multiple Threads
Meerdere threads
1015
The main benefit of the Time State system is that it can be safely used across threads or live loops. For example, you could have one live loop setting information and another one getting it:
Het belangrijkste voordeel van het tijd toestand systeem is dat het veilig gebruikt kan worden tussen meerdere threads of live lussen. Je kunt bijvoorbeeld een live lus hebben voor het zetten van informatie en een andere voor het ophalen:
1016
live_loop :setter do
set :foo, rrand(70, 130)
sleep 1
end
live_loop :getter do
puts get[:foo]
sleep 0.5
end
live_loop :opslaan do
set :foo, rrand(70, 130)
sleep 1
end
live_loop :ophalen do
puts get[:foo]
sleep 0.5
end
1017
The nice thing about using `get` and `set` across threads like this is that it will always produce the same result every time you hit run. Go on, try it. See if you get the following in your log:
Het leuke aan het gebruik van `get` en `set` tussen meerdere threads zoals hier is dat het altijd hetzelfde resultaat oplevert iedere keer dat je op uitvoeren drukt. Vooruit, probeer het. Kijk op je het volgende in je log krijgt:
1018
{run: 0, time: 0.0}
└─ 125.72265625
{run: 0, time: 0.5}
└─ 125.72265625
{run: 0, time: 1.0}
└─ 76.26220703125
{run: 0, time: 1.5}
└─ 76.26220703125
{run: 0, time: 2.0}
└─ 114.93408203125
{run: 0, time: 2.5}
└─ 114.93408203125
{run: 0, time: 3.0}
└─ 75.6048583984375
{run: 0, time: 3.5}
└─ 75.6048583984375
{run: 0, time: 0.0}##run: draai
└─ 125.72265625
{run: 0, time: 0.5}##run: draai
└─ 125.72265625
{run: 0, time: 1.0}##run: draai
└─ 76.26220703125
{run: 0, time: 1.5}##run: draai
└─ 76.26220703125
{run: 0, time: 2.0}##run: draai
└─ 114.93408203125
{run: 0, time: 2.5}##run: draai
└─ 114.93408203125
{run: 0, time: 3.0}##run: draai
└─ 75.6048583984375
{run: 0, time: 3.5}##run: draai
└─ 75.6048583984375
1019
Try running it a few times - see, it's the same every time. This is what we call deterministic behaviour and it's really very important when we want to share our music as code and know that the person playing the code is hearing exactly what we wanted them to hear (just like playing an MP3 or internet stream sounds the same for all listeners).
Probeer het een paar keer uit te voeren, zie je wel, het is steeds hetzelfde. Dit is wat we deterministisch gerag noemen en het is werkelijk heel belangrijk wanneer we onze muziek als code willen delen en zeker willen weten dat de persoon die code afspeelt exact hetzelfde hoort als wat we wilden dat ze hoorden (net als een MP3 afpselen of een internet stream voor alle luisteraars hezelfde klinkt).
1020
A Simple Deterministic State System
Een simple deterministisch toestandssysteem
1021
Back in Section 5.6 we discussed why using variables across threads can lead to random behaviour. This stops us from being able to reliably reproduce code such as this:
Eerder, in sectie 5.6, bespraken we waarom variabelen gebruiken over meerdere threads voor willekeurig gedrag kan zorgen. Daardoor is het betrouwbaar reproduceren zoals de volgende code niet mogelijk:
1022
## An Example of Non-Deterministic Behaviour
## (due to race conditions caused by multiple
## live loops manipulating the same variable
## at the same time).
##
## If you run this code you'll notice
## that the list that's printed is
## not always sorted!
a = (ring 6, 5, 4, 3, 2, 1)
live_loop :shuffled do
a = a.shuffle
sleep 0.5
end
live_loop :sorted do
a = a.sort
sleep 0.5
puts "sorted: ", a
end
## Een voorbeeld van niet deterministisch gedrag
## (veroorzaakt door race condities veroorzaakt door meerdere
## live lussen die dezelfde variable manipuleren
## op hetzelfde moment).
##
## Wanneer je deze code uitvoert zul je opmerken
## dat de lijst die wordt afgedrukt
## niet altijd gesorteerd is
a = (ring 6, 5, 4, 3, 2, 1)
live_loop :geschud do
a = a.shuffle
sleep 0.5
end
live_loop :gesorteerd do
a = a.sort
sleep 0.5
puts "gesorteerd: ", a
end
a year ago anonymous has suggested
Het leuke aan het gebruik van `get` en `set` tussen meerdere threads zoals hier is dat het altijd hetzelfde resultaat oplevert iedere keer dat je op uitvoeren drukt. Vooruit, probeer het. Kijk of je het volgende in je log krijgt:

Suggested change:

Het leuke aan het gebruik van `get` en `set` tussen meerdere threads zoals hier is dat het altijd hetzelfde resultaat oplevert iedere keer dat je op uitvoeren drukt. Vooruit, probeer het. Kijk opf je het volgende in je log krijgt:

Loading…

Loading…

Things to check

Glossary

Source Translation
No related strings found in the glossary.

Source information

Source string location
10.1-Set-and-Get.md:70
Source string age
a year ago
Translation file
etc/doc/lang/sonic-pi-tutorial-nl.po, string 1017
String priority
Medium