last post from EgonOlsen71 at the
sparhawk just curious: Warum für einen patch/Anpassung gleich einen neuen fork machen? Grundsätzlich müsste ein eigener (lokaler) branch ausreichen, welchen Du gelegentlich auf master rebasen kannst. So bewegen sich beide Stände nicht zu weit auseinander und falls es dennoch dann mal zu einem conflict kommen sollte, diesen beheben und weiter gehts 
Somit könntest Du Dir diese ganze Rumhantiererei mit einem eigenen fork und dessen Aktualisierung imho komplett sparen - So zumindest unter git.
sparhawk just curious: Warum für einen patch/Anpassung gleich einen neuen fork machen? Grundsätzlich müsste ein eigener (lokaler) branch ausreichen, welchen Du gelegentlich auf master rebasen kannst. So bewegen sich beide Stände nicht zu weit auseinander und falls es dennoch dann mal zu einem conflict kommen sollte, diesen beheben und weiter gehts
Somit könntest Du Dir diese ganze Rumhantiererei mit einem eigenen fork und dessen Aktualisierung imho komplett sparen - So zumindest unter git.
Ich habe ja keine Schreibberechtigung auf dem ursprünglichen Master. Das ist aber IMO gängige Praxis. Ich will was für wxWidgets (oder irgendein anderes Projekt) entwickeln, also erzeuge ich mir einen Fork auf dem ich tun kann was ich will. Da erzeuge ich einen Branch mit den Änderungen die ich gerne beisteuern will. Für diesen Branch erstelle ich dann einen Pullrequest gegen das Originalprojekt. Wenn die das übernehmen, dann kann ich meine Änderungen nach dem Merge in meinen Forkmaster übernehmen und ich bin wieder auf dem gleichen Stand, der Branch wird danach ja gelöscht. Meinen eigenen Master verwende ich nur als Snychronisation zum Original, aber ich merge keine Branches rein, sonst laufen die auseinander. Dann wäre dein Fork ein echter Fork der zwar von dem Original abgeleitet ist, aber nicht mehr zwingend kompatibel bleibt.
Die Alternative wäre dass ich halt auf dem Originalprojekt einen eigenen Branch bekomme, den ich dann für meine Änderungen verwende, dann wäre es etwas kürzer, aber soweit ich das gesehen habe ist das bei keinem Projekt so.
Der Fork wird erst zum Problem wenn ich anfange eigene Branches zu mergen und dann aber mit dem Master snychronisieren will.
Die Alternative wäre dass ich halt auf dem Originalprojekt einen eigenen Branch bekomme, den ich dann für meine Änderungen verwende, dann wäre es etwas kürzer, aber soweit ich das gesehen habe ist das bei keinem Projekt so.
Der Fork wird erst zum Problem wenn ich anfange eigene Branches zu mergen und dann aber mit dem Master snychronisieren will.
Nein, Du benötigst in dem Originalprojekt keinen eigenen branch, denn mein Ansatz war _local_: Also das offizielle Projekt local auschecken, dort erstellst Du Dir auf Basis von master einen eigenen Branch, auf welchem Du arbeitest. Ob Du local einen eigenen Branch hast oder nicht, interessiert das offizielle repository ja nicht. So kannst Du halt immer zwischendurch Dir den aktuellen master holen und Deinen Branch auf den dann aktuellen master rebasen. Dadurch siehst Du rechtzeitig, wenn es conflicts geben sollte und kannst diese umgehend beheben. Basierend auf Deinem local branch kannst Du dann ggf. merge-/pull-requests erstellen.
Nein, Du benötigst in dem Originalprojekt keinen eigenen branch, denn mein Ansatz war _local_: Also das offizielle Projekt local auschecken, dort erstellst Du Dir auf Basis von master einen eigenen Branch, auf welchem Du arbeitest.
Ja, das ginge natürlich auch, wenn ich nur auf einem Computer arbeiten würde. 
Die Alternative wäre dass ich halt auf dem Originalprojekt einen eigenen Branch bekomme, den ich dann für meine Änderungen verwende, dann wäre es etwas kürzer, aber soweit ich das gesehen habe ist das bei keinem Projekt so.
Der Fork wird erst zum Problem wenn ich anfange eigene Branches zu mergen und dann aber mit dem Master snychronisieren will.
Nein, Du benötigst in dem Originalprojekt keinen eigenen branch, denn mein Ansatz war _local_: Also das offizielle Projekt local auschecken, dort erstellst Du Dir auf Basis von master einen eigenen Branch, auf welchem Du arbeitest. Ob Du local einen eigenen Branch hast oder nicht, interessiert das offizielle repository ja nicht. So kannst Du halt immer zwischendurch Dir den aktuellen master holen und Deinen Branch auf den dann aktuellen master rebasen. Dadurch siehst Du rechtzeitig, wenn es conflicts geben sollte und kannst diese umgehend beheben. Basierend auf Deinem local branch kannst Du dann ggf. merge-/pull-requests erstellen.
Das ist aber doch ein fork, nur weil man nicht bei github den fork-button drückt ist das doch trotzdem ein fork?!
Die Alternative wäre dass ich halt auf dem Originalprojekt einen eigenen Branch bekomme, den ich dann für meine Änderungen verwende, dann wäre es etwas kürzer, aber soweit ich das gesehen habe ist das bei keinem Projekt so.
Der Fork wird erst zum Problem wenn ich anfange eigene Branches zu mergen und dann aber mit dem Master snychronisieren will.
Nein, Du benötigst in dem Originalprojekt keinen eigenen branch, denn mein Ansatz war _local_: Also das offizielle Projekt local auschecken, dort erstellst Du Dir auf Basis von master einen eigenen Branch, auf welchem Du arbeitest. Ob Du local einen eigenen Branch hast oder nicht, interessiert das offizielle repository ja nicht. So kannst Du halt immer zwischendurch Dir den aktuellen master holen und Deinen Branch auf den dann aktuellen master rebasen. Dadurch siehst Du rechtzeitig, wenn es conflicts geben sollte und kannst diese umgehend beheben. Basierend auf Deinem local branch kannst Du dann ggf. merge-/pull-requests erstellen.
Das ist aber doch ein fork, nur weil man nicht bei github den fork-button drückt ist das doch trotzdem ein fork?!
Nein, weder ein lokales auschecken, noch einen neuen branch zu erstellen, ist ein Fork: Bei einem lokalem auschecken eines repositories nutzt Du ja weiterhin dieselbe remote.origin.url. Ein fork wäre es, wenn Du daraus ein neues, eigenständiges repository machst, welches dann auch eine andere remote.origin.url hat.
Nein, weder ein lokales auschecken, noch einen neuen branch zu erstellen, ist ein Fork: Bei einem lokalem auschecken eines repositories nutzt Du ja weiterhin dieselbe remote.origin.url. Ein fork wäre es, wenn Du daraus ein neues, eigenständiges repository machst, welches dann auch eine andere remote.origin.url hat.
Huh, entsteht der fork nicht dadurch das sich die timeline gabelt und (vermutlich) nicht mehr zusammen findet, daher halt die (weg-)gabelung?
Man kann git ja auch mehrstufig nutzen ohne zu forken, da ändert man ja zumindest die push-url.
Du meinst ein Fork entsteht durch git remtore set-url?
Was ist ein eigenständiges repository? eins ohne eingetragenes origin?
Wenn ich jetzt ein git clone $url repo1 habe ich im ordner repo1 kein fork, da sind wir uns einig, ja?
wenn ich dann anschließend ein git clone repo1 repo2 mache, ist in repo2 dan ein fork?
Huh, entsteht der fork nicht dadurch das sich die timeline gabelt und (vermutlich) nicht mehr zusammen findet, daher halt die (weg-)gabelung?
Man kann git ja auch mehrstufig nutzen ohne zu forken, da ändert man ja zumindest die push-url.
Was meinst Du mit "timeline gabeln"? Meinst Du damit die (visualisierte) commit history mit möglichen Verzweigungen?
Das sind keine forks, sondern branches mit ihren Abzweigungen von anderen branches.
Du meinst ein Fork entsteht durch git remtore set-url?
Was ist ein eigenständiges repository? eins ohne eingetragenes origin?
Ein fork eines repositories entsteht dadurch, als das der fork keinerlei Verbindung mehr zum ursprünglichen repository hat, welches durch Änderung der origin url der Fall ist. Du übernimmst zwar die codebasis/commit history, bist aber dann owner des neuen repositories und alle bisherigen committer können/dürfen nichts mehr zu "Deinem" repository beitragen, sofern Du denen nicht die Berechtigung erteilst. Das meine ich mit "eigenständigem" repository.
Wenn ich jetzt ein git clone $url repo1 habe ich im ordner repo1 kein fork, da sind wir uns einig, ja?
Korrekt, Du hast damit einen clone eines remote repository local in einem Ordner "repo1" angelegt.
wenn ich dann anschließend ein git clone repo1 repo2 mache, ist in repo2 dan ein fork?
Nein, das ist kein fork. Es ist der clone eines clones des ursprünglichen repositories. Alle drei haben nach wie vor dieselbe git-Konfiguration - und somit dieselbe remote.origin.url.
Huh, entsteht der fork nicht dadurch das sich die timeline gabelt und (vermutlich) nicht mehr zusammen findet, daher halt die (weg-)gabelung?
Man kann git ja auch mehrstufig nutzen ohne zu forken, da ändert man ja zumindest die push-url.
Was meinst Du mit "timeline gabeln"? Meinst Du damit die (visualisierte) commit history mit möglichen Verzweigungen?
Das sind keine forks, sondern branches mit ihren Abzweigungen von anderen branches.
genau, wenn sich der weg des einen repos abgabelt vom anderen.
Klar, branches machen das auch, temporär, aber in den allermeisten fällen winden sie ja wieder "den weg zurück"
Du meinst ein Fork entsteht durch git remtore set-url?
Was ist ein eigenständiges repository? eins ohne eingetragenes origin?
Ein fork eines repositories entsteht dadurch, als das der fork keinerlei Verbindung mehr zum ursprünglichen repository hat, welches durch Änderung der origin url der Fall ist. Du übernimmst zwar die codebasis/commit history, bist aber dann owner des neuen repositories und alle bisherigen committer können/dürfen nichts mehr zu "Deinem" repository beitragen, sofern Du denen nicht die Berechtigung erteilst. Das meine ich mit "eigenständigem" repository.
wenn ich ein repo clone kann auf dem geklonten repo ja eh erstmal niemand mehr etwas commiten der kein zugriff auf mein lokales dateisystem hat, das ist in der regel niemand ausser mir.
wenn ich dann anschließend ein git clone repo1 repo2 mache, ist in repo2 dan ein fork?
Nein, das ist kein fork. Es ist der clone eines clones des ursprünglichen repositories. Alle drei haben nach wie vor dieselbe git-Konfiguration - und somit dieselbe remote.origin.url.
nein, das stimmt nicht, das repo2 hat als origin url das repo1 gesetzt.
Demnach ist repo2 jetzt doch ein fork?
IMO ist das ein wenig Haarspalterei. Wenn ich in github einen Fork erzeuge, dann ist das so gesehen auch erstmal ein Clone. Ich kann ja sogar vom Originalrepo in meinen Master reinmergen, die "Verbindung" ist also durchaus noch da.
Als echten Fork würde ich es ansehen, wenn ich anfange in meinem Master Branches reinmerge die verhindern daass ich das Original nicht mehr ohne weiteres reinmergen kann. Solange ich auf meinem Fork nur Branches anlege und die nicht in meinen Master merge, bleibt das im Prinzip mehr ein Clone als ein Fork. Genau so mache ich das ja mit meinem wxWidgets Fork. Der Master bleibt das Original, so dass ich das jederzeit nachziehen kann. Und für Erweiterungen merge ich meinen Branch eben mit dem Original und hole mir meine Erweiterung in meinen Master aus der offiziellen Version zurück.
Ich könnte ja meinen Branch auch in direkt in meinen Master mergen, aber dann mache ich eben einen echten Fork draus und kann nicht mehr mit dem Original mergen weil es dann Konflikte gibt.
IMO ist das ein wenig Haarspalterei. Wenn ich in github einen Fork erzeuge, dann ist das so gesehen auch erstmal ein Clone. Ich kann ja sogar vom Originalrepo in meinen Master reinmergen, die "Verbindung" ist also durchaus noch da.
Als echten Fork würde ich es ansehen, wenn ich anfange in meinem Master Branches reinmerge die verhindern daass ich das Original nicht mehr ohne weiteres reinmergen kann. Solange ich auf meinem Fork nur Branches anlege und die nicht in meinen Master merge, bleibt das im Prinzip mehr ein Clone als ein Fork. Genau so mache ich das ja mit meinem wxWidgets Fork. Der Master bleibt das Original, so dass ich das jederzeit nachziehen kann. Und für Erweiterungen merge ich meinen Branch eben mit dem Original und hole mir meine Erweiterung in meinen Master aus der offiziellen Version zurück.
Ich könnte ja meinen Branch auch in direkt in meinen Master mergen, aber dann mache ich eben einen echten Fork draus und kann nicht mehr mit dem Original mergen weil es dann Konflikte gibt.
Darauf wollte ich auch ninaus, das von irgend einer technischen feinheit abhängig zu machen die leicht umkehrbar ist klingt komisch.
Imho ist ein fork dann gegeben wenn man sich unwiederbringlich abspalter (natürlich ist das nie unwiederbringlich, aber wenn mergen einfach keine sinnvolle option mehr ist)
https://en.wikipedia.org/wiki/Fork_(software_development)
"In software engineering, a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct and separate piece of software. The term often implies not merely a development branch, but also a split in the developer community; as such, it is a form of schism.[1] Grounds for forking are varying user preferences and stagnated or discontinued development of the original software."
Und klar kann man auch einen Branch in einem lokal geclonten Repo als "Fork" bezeichnen. Hat halt nur ein kleines bisschen was von Megalomanie. 
Ein Workaround damit man Spotify sinnvoll für Hörspiele nutzen kann.
Problem: Hörspiele kommen in der regel als lange playlisten über die gesamtdauer, manchmal aber auch "nur" als Alben daher, alben wäre dann einfach nur die CD's auf denen sie verkauft werden.
Das kann man dann natürlich problemlos von Anfang bis zu Ende hören, kein Problem.
Jetzt will man aber manchmal auch Musik hören.
z.B. bei der Arbeit, oder wenn BEsuch da ist, oder wenn man irgendwas macht was seine Aufmerksamkeit erfordert.
Jetzt wird's schwer beim Hörspiel wieder den Einstieg zu finden, mit etwas glück landet das Hörspiel und "zuletzt gehört", aber das funktioniert nicht immer.
Wenn man aber zwischenzeitlich genug musik hört ist's da auch schon wieder raus, was nun? Notizzettel?
Hello no.
Lösung:
Mein Homeassistant weiß eh schon darüber bescheid was mein Spotify so abspielt (und wenn nicht ist das auch schnell selbst implementiert).
Ich lausche jetzt also auf die Events die der Homeassistant so rauswirft über den Spotify-status, prüfe ob das jetzt der Nächste track ist und speichere mit da ne hand voll informationen weg, namentlich:
Die Spotify-media-id
Titel
Artist
Album
Tracknummer
Bild
ggf. Playlistz
Das ist der Erste teil.
Der Zweite teil:
Eine mini webseite mit einem eingabefeld das seine eingabe speichert.
Das ist ein Suchfeld für die Spotify.history.
Da gebe ich also den namen des hörspiels ein und bekomme immer wenn ich das aufmache oben den letzten track vom hörspiel angezeigt. und kann draufklicken um diesen abzuspielen.
In den letzten Wochen hatte ich beschlossen dass ich erstmal alle bekannten Bugs ausmerze. Das hat etwas länger gedauert als gedacht, weil ich da ein paar fiese Sachen hatte, die zwar funktional kein Problem waren, aber für den User hässlich sind. Man kann also mit dem Dockingmodul soweit arbeiten, aber es gibt ein paar so Stellen wo sich User dann melden würden und sagen dass das nicht richtig funktionieren würde, obwohl das nur Anzeigeprobleme waren. Auf jeden Fall wollte ich vermeiden dass ich da später nochmal ran muss, wenn ich schon alles vergessen habe und mich dann in diesen Teil wieder einarbeiten muss. Da ich zwischendurch aber auch was anderes machen wollte, hatte ich auch noch mein Erweiterung für wxWidgets eingreicht,die ja mittlerweile auch gemerged worden war.
Jetzt muss ich nur noch ein Overlay machen, damit man auch noch an den letzten Stellen andocken kann, aber das sollte an dem eigentlichen Dockingmechanismuss nichts mehr ändern, da das nur eine Anzeige ist die gewisse Dockingmaneuver erleichtert, weil die nicht einfach durch Mausbewegungen erkannt werden können.
Konkret gehts darum dass man im Moment nicht unterscheiden kann, wenn man an ein Tabcontrol docken will, ob der User jetzt das Fenster über den Tabs platzieren will, oder ob er das Fenster in das Tabcontrol zwischen zwei Tabs reinziehen will. Das liegt halt daran das bei Tabcontrols ja die Tabs im Weg sind denn die können ja auch ein Dockingziel sein. Deshalb werde ich da so ein Overlay einbauen, wie es auch in Visual Studio benutzt wird, bei dem der User das dann einfach auswählen kann indem er über den entsprechenden Button zieht.
Das wird ja dann hoffentlich nicht mehr allzulange dauern und dann wäre ich mit dem ersten Abschnitt tatsächlich komplett fertig und kann mich dem nächsten Kapitel zuwenden, nämlich der Unterstützung für Toolbars.
Endlich mal wieder im Disassembler weitergekommen. 
Obwohl mir bekannt ist bei VB.net immer ab 0 gezählt wird (und nicht ab 1 wie in VBA), hatten sich trotzdem zwei kleine Fehler eingeschlichen. 
Weiter gehts... 
Obwohl mir bekannt ist bei VB.net immer ab 0 gezählt wird (und nicht ab 1 wie in VBA)
Hmm, ich kenne mich mit beiden aus... was wird in VB.Net bei 0 und in VBA bei 1 los gezählt?
Obwohl mir bekannt ist bei VB.net immer ab 0 gezählt wird (und nicht ab 1 wie in VBA)
Hmm, ich kenne mich mit beiden aus... was wird in VB.Net bei 0 und in VBA bei 1 los gezählt?
Ein Array z.B. funktioniert in VB.net wie in jeder anderen normalen Sprache und startet bei Null.
Ebenso ein String. Nicht aber in VBA. Wenn man da z.B. in einem String was sucht, dann wird
immer von 1 gerechnet.
Nicht aber in VBA. Wenn man da z.B. in einem String was sucht, dann wird
immer von 1 gerechnet.
Das kann man so nicht sagen. Wenn Du .IndexOf benutzt, startet es bei 0, wenn Du aber z. B. InStr benutzt, startet der String bei 1. Ganz viele Sachen kann man von VBA einfach in VB.Net reinkopieren und läuft.
Ganz viele Sachen kann man von VBA einfach in VB.Net reinkopieren und läuft.
Interessant. Meine Erfahrungen entsprechen eher dem Gegenteil Deiner Aussage.
Wenn ich auf der Arbeit mit VBA coden muss, dann kann ich oft nur mit Mühe ein
zurück halten.
oobdoo Naja, VB/VBA ist ja kein Z80
Aber im Ernst: ich probiere auf der Arbeit in Access recht viel aus, manche Funktions-Prototypen (die ich natürlich schon so programmiere, damit es funktioniert) kopiere ich dann aus Access einfach ins VB.Net rein. Und von der Geschwindigkeit her macht es keinen wirklichen Unterschied.
Zudem kommt mir entgegen, dass beide VB-Typen von einem C64-Programmierer leicht verstanden werden, wobei VBA da noch deutlich näher am Basic V2 ist.
