You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(39) |
Nov
(277) |
Dec
(299) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(261) |
Feb
(162) |
Mar
(70) |
Apr
(141) |
May
(55) |
Jun
(166) |
Jul
(202) |
Aug
(122) |
Sep
(368) |
Oct
(290) |
Nov
(232) |
Dec
(516) |
2010 |
Jan
(302) |
Feb
(253) |
Mar
(253) |
Apr
(184) |
May
(184) |
Jun
(82) |
Jul
(62) |
Aug
(154) |
Sep
(331) |
Oct
(450) |
Nov
(312) |
Dec
(249) |
2011 |
Jan
(252) |
Feb
(286) |
Mar
(175) |
Apr
(175) |
May
(194) |
Jun
(130) |
Jul
(211) |
Aug
(340) |
Sep
(150) |
Oct
(398) |
Nov
(572) |
Dec
(199) |
2012 |
Jan
(458) |
Feb
(378) |
Mar
(332) |
Apr
(385) |
May
(228) |
Jun
(188) |
Jul
(199) |
Aug
(336) |
Sep
(349) |
Oct
(271) |
Nov
(61) |
Dec
(155) |
2013 |
Jan
(230) |
Feb
(302) |
Mar
(350) |
Apr
(162) |
May
(118) |
Jun
(209) |
Jul
(75) |
Aug
(94) |
Sep
(32) |
Oct
(92) |
Nov
(276) |
Dec
(84) |
2014 |
Jan
(36) |
Feb
(50) |
Mar
(16) |
Apr
(32) |
May
(61) |
Jun
(233) |
Jul
(37) |
Aug
(13) |
Sep
(23) |
Oct
(38) |
Nov
(52) |
Dec
(34) |
2015 |
Jan
(9) |
Feb
(18) |
Mar
(148) |
Apr
(78) |
May
(15) |
Jun
(31) |
Jul
(60) |
Aug
(90) |
Sep
(41) |
Oct
(38) |
Nov
(177) |
Dec
(76) |
2016 |
Jan
(53) |
Feb
(41) |
Mar
(26) |
Apr
(25) |
May
(34) |
Jun
(44) |
Jul
(22) |
Aug
(1) |
Sep
(15) |
Oct
(18) |
Nov
(1) |
Dec
(16) |
2017 |
Jan
(29) |
Feb
(20) |
Mar
(5) |
Apr
(8) |
May
(6) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
(25) |
Mar
(7) |
Apr
(2) |
May
(4) |
Jun
(9) |
Jul
|
Aug
(17) |
Sep
(6) |
Oct
(8) |
Nov
(7) |
Dec
(19) |
2019 |
Jan
(2) |
Feb
(31) |
Mar
(10) |
Apr
(1) |
May
(4) |
Jun
(3) |
Jul
(13) |
Aug
(5) |
Sep
|
Oct
(4) |
Nov
(164) |
Dec
(59) |
2020 |
Jan
(16) |
Feb
(20) |
Mar
(124) |
Apr
(236) |
May
(128) |
Jun
(31) |
Jul
(54) |
Aug
(34) |
Sep
|
Oct
(6) |
Nov
(30) |
Dec
(28) |
2021 |
Jan
(18) |
Feb
(6) |
Mar
(4) |
Apr
(44) |
May
(61) |
Jun
(178) |
Jul
(49) |
Aug
(44) |
Sep
(104) |
Oct
(75) |
Nov
(56) |
Dec
(61) |
2022 |
Jan
(177) |
Feb
(111) |
Mar
(36) |
Apr
(17) |
May
(10) |
Jun
(24) |
Jul
(17) |
Aug
(81) |
Sep
(19) |
Oct
(51) |
Nov
(36) |
Dec
(20) |
2023 |
Jan
(41) |
Feb
(37) |
Mar
(37) |
Apr
(19) |
May
(15) |
Jun
(7) |
Jul
(38) |
Aug
(8) |
Sep
(12) |
Oct
(2) |
Nov
(4) |
Dec
(45) |
2024 |
Jan
(11) |
Feb
(22) |
Mar
(160) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Robert R. <io...@us...> - 2024-03-22 00:53:31
|
Converting the menus to classes is straightforward but time consuming. One problem I found is the credits menu consists of a separate menu for each page. Another issue with using RAII and a tree of menus is that it would require duplicates of the same menu. Right now there is only a single instance for duplicate menus and ownership is transferred. There are memory leaks and ownership issues everywhere but there is a way to register the C portion of a menu for deletion later but it's not used. The C++ menus are not automatically deleted. Each C++ menu is handled differently. The menus are created on demand so having duplicate menus doesn't make much difference for modern machines. I still think RAII the way to go because there are no explicit memory allocations and pointer use in minimized. You don't have to think about resource allocation and lifetime. When all menus are converted to classes references could be used in place of pointers for the C++ portion. Because the C++ classes are wrappers for the C menus there is still the C mess of pointers and memory allocations but they would be managed by the C++ code. --- **[tickets:#1269] remove plib usage from non-graphics code** **Status:** new **Milestone:** 2.4.0 **Created:** Fri Mar 15, 2024 01:49 AM UTC by Robert Reif **Last Updated:** Wed Mar 20, 2024 06:59 PM UTC **Owner:** nobody **Attachments:** - [t2Dd.diff](https://sourceforge.net/p/speed-dreams/tickets/1269/attachment/t2Dd.diff) (3.6 kB; application/octet-stream) Our interface includes can no longer be used as a C interface because we are including plib C++ template types in them. Since we want to migrate from plib to osg we should start by removing plib dependencies from core non-graphic code. The interface `src/interfaces/track.h` uses a plib type. The attached patch creates an equivalent type in `src/libs/tgf/tgf.h` and uses it. The patch assumes we will no longer try to maintain a C interface. If this approach is acceptable then I will do the same thing to `src/interfaces/car.h`. --- Sent from sourceforge.net because spe...@li... is subscribed to https://sourceforge.net/p/speed-dreams/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/speed-dreams/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Robert R. <io...@us...> - 2024-03-20 18:59:17
|
I'm working on the code now replacing the singletons with RAII. I am doing it incrementally but I'm not going to commit it incrementally. My experiences with doing SD refactoring like this is 9 times out of 10 it fails because it uncovers other fundamental flaws that need to be fixed first. I hope to have something in a few weeks --- **[tickets:#1269] remove plib usage from non-graphics code** **Status:** new **Milestone:** 2.4.0 **Created:** Fri Mar 15, 2024 01:49 AM UTC by Robert Reif **Last Updated:** Wed Mar 20, 2024 02:18 PM UTC **Owner:** nobody **Attachments:** - [t2Dd.diff](https://sourceforge.net/p/speed-dreams/tickets/1269/attachment/t2Dd.diff) (3.6 kB; application/octet-stream) Our interface includes can no longer be used as a C interface because we are including plib C++ template types in them. Since we want to migrate from plib to osg we should start by removing plib dependencies from core non-graphic code. The interface `src/interfaces/track.h` uses a plib type. The attached patch creates an equivalent type in `src/libs/tgf/tgf.h` and uses it. The patch assumes we will no longer try to maintain a C interface. If this approach is acceptable then I will do the same thing to `src/interfaces/car.h`. --- Sent from sourceforge.net because spe...@li... is subscribed to https://sourceforge.net/p/speed-dreams/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/speed-dreams/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Robert R. <io...@us...> - 2024-03-20 14:18:27
|
I have already rewritten several menus in C++ removing the singletons as I go. Each menu own it's sub-menus and the module owns the main menu. some C menus are easy to convert but some are difficult. When I'm finished some of the C API will just be member functions of the base class. --- **[tickets:#1269] remove plib usage from non-graphics code** **Status:** new **Milestone:** 2.4.0 **Created:** Fri Mar 15, 2024 01:49 AM UTC by Robert Reif **Last Updated:** Wed Mar 20, 2024 09:02 AM UTC **Owner:** nobody **Attachments:** - [t2Dd.diff](https://sourceforge.net/p/speed-dreams/tickets/1269/attachment/t2Dd.diff) (3.6 kB; application/octet-stream) Our interface includes can no longer be used as a C interface because we are including plib C++ template types in them. Since we want to migrate from plib to osg we should start by removing plib dependencies from core non-graphic code. The interface `src/interfaces/track.h` uses a plib type. The attached patch creates an equivalent type in `src/libs/tgf/tgf.h` and uses it. The patch assumes we will no longer try to maintain a C interface. If this approach is acceptable then I will do the same thing to `src/interfaces/car.h`. --- Sent from sourceforge.net because spe...@li... is subscribed to https://sourceforge.net/p/speed-dreams/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/speed-dreams/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: <bh...@ic...> - 2024-03-20 11:03:16
|
On Wed, 20 Mar 2024 10:49:33 +0100 Adrien 'neox' Bourmault <ne...@gn...> wrote: > > What will happen if this person desappear or will do some bad things? > > Libre en Communs is a structure that emphasizes exchange and communication > between humans (fairly little automation in the processes), so I have good > reason to think that if something happens, discussion and exchange will help > remedy it. Thank you very much for your clarifications. So we can count on support from the Libre en Communs if the community will lose access to administrative accounts, right? > To conclude, the Libre en Communs board will require the signatures of several > people anyway, and it's up to you as a project to define who is legitimate for > this kind of agreement. Looks like all are agree with the suggestion of Libre en Communs. I think will be better if we create a new topic for choosing our representatives. Because is a bit different question and also will be good to draw more attention to it. icy |
From: Adrien 'n. B. <ne...@gn...> - 2024-03-20 09:50:08
|
Le mercredi 20 mars 2024 à 11:41 +0700, bh...@ic... a écrit : > > Who will sign the agreement? > We actually have no any official representativity. > We have only set of commits, emails and chat messages. I'm not specifically a lawyer. However, it appears to me personally that Speed Dreams is a collective project, and in France it qualifies as an association de fait (which means it's an undeclared legal structure, but at least an existing one). Libre en Communs will need the signature of the people running the project, representing the project and not themselves specifically. > > At codeberg we don't need to sign official documents. At Codeberg, the signature is implicit: compliance with the GTUs and platform rules. What's more, Codeberg does not provide VPS (to my knowledge). > Also at codeberg we can create several admins (will be their rights equal to > the > org creator?) At Libre en Communs too (same software). > > Looks like after signing the agreement, moving repos, and fully configuring > the > VPS - a single person will own the domain, repo, bug/issue traker, wiki, > forum/mail-list and chat-rooms. > I'm not familiar with your current situation, but I have the impression that it's already the case: someone owns the domain and a VPS. As for the rest, as I said above: - for repositories, wiki, issue tracker, it's the same system as Codeberg (several admins possible) - for the VPS, several admins possible too. > What will happen if this person desappear or will do some bad things? Libre en Communs is a structure that emphasizes exchange and communication between humans (fairly little automation in the processes), so I have good reason to think that if something happens, discussion and exchange will help remedy it. To conclude, the Libre en Communs board will require the signatures of several people anyway, and it's up to you as a project to define who is legitimate for this kind of agreement. Let me know if you have other concerns, Happy hacking! -- Adrien Bourmault Trésorier et responsable Cominfra, Libre en Communs Maintainer, GNU Boot project Elected member, XMPP Standards Foundation GPG : 393D4CC68136F39799DA75F295F65F55F682A17A |
From: IcyStar <ic...@us...> - 2024-03-20 09:25:41
|
i'll work on code of menus --- **[tickets:#1269] remove plib usage from non-graphics code** **Status:** new **Milestone:** 2.4.0 **Created:** Fri Mar 15, 2024 01:49 AM UTC by Robert Reif **Last Updated:** Wed Mar 20, 2024 09:02 AM UTC **Owner:** nobody **Attachments:** - [t2Dd.diff](https://sourceforge.net/p/speed-dreams/tickets/1269/attachment/t2Dd.diff) (3.6 kB; application/octet-stream) Our interface includes can no longer be used as a C interface because we are including plib C++ template types in them. Since we want to migrate from plib to osg we should start by removing plib dependencies from core non-graphic code. The interface `src/interfaces/track.h` uses a plib type. The attached patch creates an equivalent type in `src/libs/tgf/tgf.h` and uses it. The patch assumes we will no longer try to maintain a C interface. If this approach is acceptable then I will do the same thing to `src/interfaces/car.h`. --- Sent from sourceforge.net because spe...@li... is subscribed to https://sourceforge.net/p/speed-dreams/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/speed-dreams/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: <bh...@ic...> - 2024-03-20 09:25:36
|
i'll work on code of menus |
From: Xavier D. C. <xa...@us...> - 2024-03-20 09:02:39
|
@iobyte FYI, in the past I had attempted to fix the convoluted mess that is menu handling in SD, and provided a simple std::stack, singleton-based class: https://gitea.privatedns.org/xavi/speed-dreams/commit/15679364986866ec396698c5822b96a09c329a8b However, the refactoring that this implied was way too big and I eventually gave up: https://gitea.privatedns.org/xavi/speed-dreams/commit/71cab484f27495496f4c2c1a7ef6ab4953cbb0bf --- **[tickets:#1269] remove plib usage from non-graphics code** **Status:** new **Milestone:** 2.4.0 **Created:** Fri Mar 15, 2024 01:49 AM UTC by Robert Reif **Last Updated:** Wed Mar 20, 2024 07:04 AM UTC **Owner:** nobody **Attachments:** - [t2Dd.diff](https://sourceforge.net/p/speed-dreams/tickets/1269/attachment/t2Dd.diff) (3.6 kB; application/octet-stream) Our interface includes can no longer be used as a C interface because we are including plib C++ template types in them. Since we want to migrate from plib to osg we should start by removing plib dependencies from core non-graphic code. The interface `src/interfaces/track.h` uses a plib type. The attached patch creates an equivalent type in `src/libs/tgf/tgf.h` and uses it. The patch assumes we will no longer try to maintain a C interface. If this approach is acceptable then I will do the same thing to `src/interfaces/car.h`. --- Sent from sourceforge.net because spe...@li... is subscribed to https://sourceforge.net/p/speed-dreams/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/speed-dreams/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Xavier D. C. <xa...@us...> - 2024-03-20 07:05:01
|
Hi @iobyte, Could you please answer to the two questions above? I think they are important to understand the motivation behind `t2D.diff`. Best regards, Xavi --- **[tickets:#1269] remove plib usage from non-graphics code** **Status:** new **Milestone:** 2.4.0 **Created:** Fri Mar 15, 2024 01:49 AM UTC by Robert Reif **Last Updated:** Tue Mar 19, 2024 06:59 PM UTC **Owner:** nobody **Attachments:** - [t2Dd.diff](https://sourceforge.net/p/speed-dreams/tickets/1269/attachment/t2Dd.diff) (3.6 kB; application/octet-stream) Our interface includes can no longer be used as a C interface because we are including plib C++ template types in them. Since we want to migrate from plib to osg we should start by removing plib dependencies from core non-graphic code. The interface `src/interfaces/track.h` uses a plib type. The attached patch creates an equivalent type in `src/libs/tgf/tgf.h` and uses it. The patch assumes we will no longer try to maintain a C interface. If this approach is acceptable then I will do the same thing to `src/interfaces/car.h`. --- Sent from sourceforge.net because spe...@li... is subscribed to https://sourceforge.net/p/speed-dreams/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/speed-dreams/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: <bh...@ic...> - 2024-03-20 04:40:07
|
On Tue, 19 Mar 2024 21:19:45 +0100 Xavier Del Campo Romero via Speed-dreams-devel <spe...@li...> wrote: > It has been 5 days since my last email, and it looks like no one opposed > to this proposal so far. My perception is that most of us seem to agree > with it, but I will give it a couple more days just in case anyone wants > to raise concerns. Otherwise, I will send our proposal to Libre en Communs. Who will sign the agreement? We actually have no any official representativity. We have only set of commits, emails and chat messages. At codeberg we don't need to sign official documents. Also at codeberg we can create several admins (will be their rights equal to the org creator?) Looks like after signing the agreement, moving repos, and fully configuring the VPS - a single person will own the domain, repo, bug/issue traker, wiki, forum/mail-list and chat-rooms. Will it be good for the project and its declared democracy? What powers will have a person who sign the agreement? What will happen if this person desappear or will do some bad things? (sometimes bad things happen: https://blog.tox.chat/2015/07/current-situation-3/) |
From: Scott G. <sc...@gm...> - 2024-03-19 20:36:09
|
I'm supportive of your proposal. Scott On 3/19/24 3:19 PM, Xavier Del Campo Romero via Speed-dreams-devel wrote: > Hello everyone, > > It has been 5 days since my last email, and it looks like no one opposed > to this proposal so far. My perception is that most of us seem to agree > with it, but I will give it a couple more days just in case anyone wants > to raise concerns. Otherwise, I will send our proposal to Libre en Communs. > > Best regards, > > Xavier Del Campo Romero > > On 15/3/24 13:16, Xavier Del Campo Romero via Speed-dreams-devel wrote: >> Hello everyone, >> >> Sorry, my last message was sent incomplete due to a human mistake. >> >> Libre en Communs is an interesting proposal indeed. As I said on a >> previous email, having a VPS would allow us to keep existing services >> and think about others that have been requested by the community in the >> past, such as a XMPP server or a better Matrix bridge. >> >> If there are no objections, I will submit a request to Libre en Communs >> with our current proposal: >> >> - Split the current SVN repository into three Git repositories, as we >> have already discussed: code, data and non-free. Since Git access is >> virtually unlimited, there is no need for Git LFS on data repositories. >> - Migrate to Libre en Communs' Forgejo instance at >> https://forge.a-lec.org/ <https://forge.a-lec.org/> >> - Migrate current website athttps://speed-dreams.net >> <https://speed-dreams.net>, as well as the "master server", to Libre en >> Communs' VPS. As opposed to the proposal regarding Codeberg, his means >> we would no longer have to depend on icystar's VPS for the master server. >> - In the mid-term, think about new services, such as a XMPP server or an >> improved Matrix bridge. >> >> Please let me you know your feedback before sending this proposal to them. >> >> Best regards, >> >> Xavier Del Campo Romero >> >> >> On 14 March 2024 17:04:03 CET, Adrien 'neox' Bourmault<ne...@gn...> wrote: >> >> Le jeudi 14 mars 2024 à 20:04 +0700,bh...@ic... a écrit : >> >> >> >> Will you with us for a long time? >> >> >> Thanks to xavi, I figured out that you were asking about Libre en >> Communs long- >> term stability. >> >> What I can tell about that is I don't see the future, but our >> financial health >> is good with 5k€ excedent in 2022 and 300€ excendent in 2023 (see >> our 2022 >> financial report at >> https://forge.a-lec.org/AG/AG-2023/raw/branch/main/rapport_financier_2022-ALEC.pdf <https://forge.a-lec.org/AG/AG-2023/raw/branch/main/rapport_financier_2022-ALEC.pdf> >> ). Our general assembly is scheduled on march, 30th, so I can't >> provide you the >> official 2023 financial report. >> >> More and more people are participating to our infrastructure and we >> are even >> hiring people for internship and so on since 2022 and we plan to do >> so in 2024 >> too. >> >> I can also point that while Libre en Communs has been created in 2021, >> Codeberg.org has been created in 2019 which is not very older! So >> yes, we're >> both young which does not mean everything. >> >> >> >> _______________________________________________ >> Speed-dreams-devel mailing list >> Spe...@li... >> https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel >> >> >> _______________________________________________ >> Speed-dreams-devel mailing list >> Spe...@li... >> https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel |
From: Leandro V. M. <lei...@gm...> - 2024-03-19 20:24:56
|
For me, everything is perfect. Go for it! O mar., 19 de mar. de 2024 ás 21:20, Xavier Del Campo Romero via Speed-dreams-devel (<spe...@li...>) escribiu: > Hello everyone, > > It has been 5 days since my last email, and it looks like no one opposed > to this proposal so far. My perception is that most of us seem to agree > with it, but I will give it a couple more days just in case anyone wants > to raise concerns. Otherwise, I will send our proposal to Libre en Communs. > > Best regards, > > Xavier Del Campo Romero > > On 15/3/24 13:16, Xavier Del Campo Romero via Speed-dreams-devel wrote: > > Hello everyone, > > > > Sorry, my last message was sent incomplete due to a human mistake. > > > > Libre en Communs is an interesting proposal indeed. As I said on a > > previous email, having a VPS would allow us to keep existing services > > and think about others that have been requested by the community in the > > past, such as a XMPP server or a better Matrix bridge. > > > > If there are no objections, I will submit a request to Libre en Communs > > with our current proposal: > > > > - Split the current SVN repository into three Git repositories, as we > > have already discussed: code, data and non-free. Since Git access is > > virtually unlimited, there is no need for Git LFS on data repositories. > > - Migrate to Libre en Communs' Forgejo instance at > > https://forge.a-lec.org/ <https://forge.a-lec.org/> > > - Migrate current website at https://speed-dreams.net > > <https://speed-dreams.net>, as well as the "master server", to Libre en > > Communs' VPS. As opposed to the proposal regarding Codeberg, his means > > we would no longer have to depend on icystar's VPS for the master server. > > - In the mid-term, think about new services, such as a XMPP server or an > > improved Matrix bridge. > > > > Please let me you know your feedback before sending this proposal to > them. > > > > Best regards, > > > > Xavier Del Campo Romero > > > > > > On 14 March 2024 17:04:03 CET, Adrien 'neox' Bourmault <ne...@gn...> > wrote: > > > > Le jeudi 14 mars 2024 à 20:04 +0700, bh...@ic... a écrit : > > > > > > > > Will you with us for a long time? > > > > > > Thanks to xavi, I figured out that you were asking about Libre en > > Communs long- > > term stability. > > > > What I can tell about that is I don't see the future, but our > > financial health > > is good with 5k€ excedent in 2022 and 300€ excendent in 2023 (see > > our 2022 > > financial report at > > > https://forge.a-lec.org/AG/AG-2023/raw/branch/main/rapport_financier_2022-ALEC.pdf > < > https://forge.a-lec.org/AG/AG-2023/raw/branch/main/rapport_financier_2022-ALEC.pdf > > > > ). Our general assembly is scheduled on march, 30th, so I can't > > provide you the > > official 2023 financial report. > > > > More and more people are participating to our infrastructure and we > > are even > > hiring people for internship and so on since 2022 and we plan to do > > so in 2024 > > too. > > > > I can also point that while Libre en Communs has been created in > 2021, > > Codeberg.org has been created in 2019 which is not very older! So > > yes, we're > > both young which does not mean everything. > > > > > > > > _______________________________________________ > > Speed-dreams-devel mailing list > > Spe...@li... > > https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel > _______________________________________________ > Speed-dreams-devel mailing list > Spe...@li... > https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel > |
From: Xavier D. C. R. <xa...@di...> - 2024-03-19 20:20:03
|
Hello everyone, It has been 5 days since my last email, and it looks like no one opposed to this proposal so far. My perception is that most of us seem to agree with it, but I will give it a couple more days just in case anyone wants to raise concerns. Otherwise, I will send our proposal to Libre en Communs. Best regards, Xavier Del Campo Romero On 15/3/24 13:16, Xavier Del Campo Romero via Speed-dreams-devel wrote: > Hello everyone, > > Sorry, my last message was sent incomplete due to a human mistake. > > Libre en Communs is an interesting proposal indeed. As I said on a > previous email, having a VPS would allow us to keep existing services > and think about others that have been requested by the community in the > past, such as a XMPP server or a better Matrix bridge. > > If there are no objections, I will submit a request to Libre en Communs > with our current proposal: > > - Split the current SVN repository into three Git repositories, as we > have already discussed: code, data and non-free. Since Git access is > virtually unlimited, there is no need for Git LFS on data repositories. > - Migrate to Libre en Communs' Forgejo instance at > https://forge.a-lec.org/ <https://forge.a-lec.org/> > - Migrate current website at https://speed-dreams.net > <https://speed-dreams.net>, as well as the "master server", to Libre en > Communs' VPS. As opposed to the proposal regarding Codeberg, his means > we would no longer have to depend on icystar's VPS for the master server. > - In the mid-term, think about new services, such as a XMPP server or an > improved Matrix bridge. > > Please let me you know your feedback before sending this proposal to them. > > Best regards, > > Xavier Del Campo Romero > > > On 14 March 2024 17:04:03 CET, Adrien 'neox' Bourmault <ne...@gn...> wrote: > > Le jeudi 14 mars 2024 à 20:04 +0700, bh...@ic... a écrit : > > > > Will you with us for a long time? > > > Thanks to xavi, I figured out that you were asking about Libre en > Communs long- > term stability. > > What I can tell about that is I don't see the future, but our > financial health > is good with 5k€ excedent in 2022 and 300€ excendent in 2023 (see > our 2022 > financial report at > https://forge.a-lec.org/AG/AG-2023/raw/branch/main/rapport_financier_2022-ALEC.pdf <https://forge.a-lec.org/AG/AG-2023/raw/branch/main/rapport_financier_2022-ALEC.pdf> > ). Our general assembly is scheduled on march, 30th, so I can't > provide you the > official 2023 financial report. > > More and more people are participating to our infrastructure and we > are even > hiring people for internship and so on since 2022 and we plan to do > so in 2024 > too. > > I can also point that while Libre en Communs has been created in 2021, > Codeberg.org has been created in 2019 which is not very older! So > yes, we're > both young which does not mean everything. > > > > _______________________________________________ > Speed-dreams-devel mailing list > Spe...@li... > https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel |
From: Robert R. <io...@us...> - 2024-03-19 18:59:41
|
I don't thing fixing the C API is the right approach. I think it would be better to convert the existing C menus to C++ and then remove the C API. Attachments: - [menus.diff](https://sourceforge.net/p/speed-dreams/tickets/_discuss/thread/67689c89c9/ab57/a4ba/e28b/ee67/d6c9/92e9/2e37/attachment/menus.diff) (121.6 kB; application/octet-stream) --- **[tickets:#1269] remove plib usage from non-graphics code** **Status:** new **Milestone:** 2.4.0 **Created:** Fri Mar 15, 2024 01:49 AM UTC by Robert Reif **Last Updated:** Tue Mar 19, 2024 01:48 PM UTC **Owner:** nobody **Attachments:** - [t2Dd.diff](https://sourceforge.net/p/speed-dreams/tickets/1269/attachment/t2Dd.diff) (3.6 kB; application/octet-stream) Our interface includes can no longer be used as a C interface because we are including plib C++ template types in them. Since we want to migrate from plib to osg we should start by removing plib dependencies from core non-graphic code. The interface `src/interfaces/track.h` uses a plib type. The attached patch creates an equivalent type in `src/libs/tgf/tgf.h` and uses it. The patch assumes we will no longer try to maintain a C interface. If this approach is acceptable then I will do the same thing to `src/interfaces/car.h`. --- Sent from sourceforge.net because spe...@li... is subscribed to https://sourceforge.net/p/speed-dreams/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/speed-dreams/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: IcyStar <ic...@us...> - 2024-03-19 14:24:30
|
On Tue, 19 Mar 2024 13:48:45 -0000 Robert Reif via Speed-dreams-devel <spe...@li...> wrote: > RAII and smart pointers are not the same thing. Smart pointers defeat the purpose of RAII because they move ownership around. With RAII you don't need to de-initialize anything because the object and every thing it owns will be deleted when it goes out of scope. This difference is not significant in this question. > I just spent all day yesterday trying to replace the menu library screen handle void pointer with a real type. The library went OK and the C menus went OK but then I found out that some of the C++ menus pass their address through the C API. I only wasted a day but I have wasted a lot longer trying to do the same thing to other libraries in the past only to hit a dead end. It is really maddening trying to fix these APIs. May i look? What part of code you try to fix? --- **[tickets:#1269] remove plib usage from non-graphics code** **Status:** new **Milestone:** 2.4.0 **Created:** Fri Mar 15, 2024 01:49 AM UTC by Robert Reif **Last Updated:** Tue Mar 19, 2024 01:48 PM UTC **Owner:** nobody **Attachments:** - [t2Dd.diff](https://sourceforge.net/p/speed-dreams/tickets/1269/attachment/t2Dd.diff) (3.6 kB; application/octet-stream) Our interface includes can no longer be used as a C interface because we are including plib C++ template types in them. Since we want to migrate from plib to osg we should start by removing plib dependencies from core non-graphic code. The interface `src/interfaces/track.h` uses a plib type. The attached patch creates an equivalent type in `src/libs/tgf/tgf.h` and uses it. The patch assumes we will no longer try to maintain a C interface. If this approach is acceptable then I will do the same thing to `src/interfaces/car.h`. --- Sent from sourceforge.net because spe...@li... is subscribed to https://sourceforge.net/p/speed-dreams/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/speed-dreams/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: <bh...@ic...> - 2024-03-19 14:24:23
|
On Tue, 19 Mar 2024 13:48:45 -0000 Robert Reif via Speed-dreams-devel <spe...@li...> wrote: > RAII and smart pointers are not the same thing. Smart pointers defeat the purpose of RAII because they move ownership around. With RAII you don't need to de-initialize anything because the object and every thing it owns will be deleted when it goes out of scope. This difference is not significant in this question. > I just spent all day yesterday trying to replace the menu library screen handle void pointer with a real type. The library went OK and the C menus went OK but then I found out that some of the C++ menus pass their address through the C API. I only wasted a day but I have wasted a lot longer trying to do the same thing to other libraries in the past only to hit a dead end. It is really maddening trying to fix these APIs. May i look? What part of code you try to fix? |
From: Robert R. <io...@us...> - 2024-03-19 13:48:53
|
RAII and smart pointers are not the same thing. Smart pointers defeat the purpose of RAII because they move ownership around. With RAII you don't need to de-initialize anything because the object and every thing it owns will be deleted when it goes out of scope. I just spent all day yesterday trying to replace the menu library screen handle void pointer with a real type. The library went OK and the C menus went OK but then I found out that some of the C++ menus pass their address through the C API. I only wasted a day but I have wasted a lot longer trying to do the same thing to other libraries in the past only to hit a dead end. It is really maddening trying to fix these APIs. --- **[tickets:#1269] remove plib usage from non-graphics code** **Status:** new **Milestone:** 2.4.0 **Created:** Fri Mar 15, 2024 01:49 AM UTC by Robert Reif **Last Updated:** Mon Mar 18, 2024 05:41 PM UTC **Owner:** nobody **Attachments:** - [t2Dd.diff](https://sourceforge.net/p/speed-dreams/tickets/1269/attachment/t2Dd.diff) (3.6 kB; application/octet-stream) Our interface includes can no longer be used as a C interface because we are including plib C++ template types in them. Since we want to migrate from plib to osg we should start by removing plib dependencies from core non-graphic code. The interface `src/interfaces/track.h` uses a plib type. The attached patch creates an equivalent type in `src/libs/tgf/tgf.h` and uses it. The patch assumes we will no longer try to maintain a C interface. If this approach is acceptable then I will do the same thing to `src/interfaces/car.h`. --- Sent from sourceforge.net because spe...@li... is subscribed to https://sourceforge.net/p/speed-dreams/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/speed-dreams/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: IcyStar <ic...@us...> - 2024-03-19 04:27:21
|
On Sat, 16 Mar 2024 16:01:47 -0000 Robert Reif via Speed-dreams-devel <spe...@li...> wrote: > I'm trying to promote RAII with C++ so someone doesn't have to have intimate knowledge of every single line of code before they can make a change without worrying about unintended consequences. I'm not sure that in the race sim has things suitable for RAII. Here always we have a strong objects heierarchy. And all lifetimes should be known at design time. launch - Init common data and libs - - Init UI - - - Init gameplay data - - - - Init track - - - - Init cars/drivers ...playing... - - - - Deinit cars/drivers - - - - Deinit track - - - Deinit gameplay data - - Deinit UI - Deinit common data and libs exit Nobody want to load a marshal tower from hdd while passing the turn. And at other side holding some track-data in memory after the race is exited is also bug. As like as keeping the wrong pointer. And such bugs also diffcult to find and fix. RAII looks good while you do not have it. But when you've finally implemented it you'll wonder that instead of pointers swamp you have swamp of smart handles (shared_ptr and analogues). And you absolutelly cannot predict an object lifetime. And you cannot understand why at new track you see cars and skidmarks from previous race and how to fix it. When we know (or should to know) an object lifetime - we do nit need raii. When we don't know an object lifetime - we need to fix code and make lifetime predefined, so we also don't need raii. And only in cases when we really need an object with floating lifetime (and mostly with floating ownership) we need to use raii for this particular object type. On Mon, 18 Mar 2024 17:41:47 -0000 Robert Reif via Speed-dreams-devel <spe...@li...> wrote: > I just took a look at fixing #1273. This involves adding a new menu. The menu code is part C and part C++. The menu code passes around void pointers everywhere because of it's C origins and it's use of C function calls. This makes figuring out how the code works difficult. It also make debugging difficult because you don't even know what the void pointer is pointing to. You also have no idea of the lifetime of the data the void pointer points to. I decided to give up on trying to fix this ticket because it's just too hard to figure out all the relationships. This is pretty typical. I'm not against a concrete improvements in places there it will take benefits. But i'm against of "converting just for converting". I've already worked with UI and remember that communication between parts of UI and between UI and game was ugly. But i'm sure that it was not related with C restrictions. I think we need to rework UI to make an immediate mode UI (like: https://immediate-mode-ui.github.io/Nuklear) So we will solve diffrent problems with callbacks and user-pointers associated with buttons and lists items. Because in this types of IU you handle events in the same place where you declare appropriate UI element. It looks like this: void drawUI(UI *ui) { if (uiButton(ui, "help")) showHelp(); uiScrollboxBegin(ui, "tracks", 250, 400); // pass width and height of the scrollbox (track list) for(int i = 0; i < tracksCnt; ++i) if (uiButton(ui, tracks[i].name) startTrack(i); uiScrollboxEnd(ui); if (uiButton(ui, "exit")) doExit(); } icy --- **[tickets:#1269] remove plib usage from non-graphics code** **Status:** new **Milestone:** 2.4.0 **Created:** Fri Mar 15, 2024 01:49 AM UTC by Robert Reif **Last Updated:** Mon Mar 18, 2024 05:41 PM UTC **Owner:** nobody **Attachments:** - [t2Dd.diff](https://sourceforge.net/p/speed-dreams/tickets/1269/attachment/t2Dd.diff) (3.6 kB; application/octet-stream) Our interface includes can no longer be used as a C interface because we are including plib C++ template types in them. Since we want to migrate from plib to osg we should start by removing plib dependencies from core non-graphic code. The interface `src/interfaces/track.h` uses a plib type. The attached patch creates an equivalent type in `src/libs/tgf/tgf.h` and uses it. The patch assumes we will no longer try to maintain a C interface. If this approach is acceptable then I will do the same thing to `src/interfaces/car.h`. --- Sent from sourceforge.net because spe...@li... is subscribed to https://sourceforge.net/p/speed-dreams/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/speed-dreams/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: <bh...@ic...> - 2024-03-19 04:27:17
|
On Sat, 16 Mar 2024 16:01:47 -0000 Robert Reif via Speed-dreams-devel <spe...@li...> wrote: > I'm trying to promote RAII with C++ so someone doesn't have to have intimate knowledge of every single line of code before they can make a change without worrying about unintended consequences. I'm not sure that in the race sim has things suitable for RAII. Here always we have a strong objects heierarchy. And all lifetimes should be known at design time. launch - Init common data and libs - - Init UI - - - Init gameplay data - - - - Init track - - - - Init cars/drivers ...playing... - - - - Deinit cars/drivers - - - - Deinit track - - - Deinit gameplay data - - Deinit UI - Deinit common data and libs exit Nobody want to load a marshal tower from hdd while passing the turn. And at other side holding some track-data in memory after the race is exited is also bug. As like as keeping the wrong pointer. And such bugs also diffcult to find and fix. RAII looks good while you do not have it. But when you've finally implemented it you'll wonder that instead of pointers swamp you have swamp of smart handles (shared_ptr and analogues). And you absolutelly cannot predict an object lifetime. And you cannot understand why at new track you see cars and skidmarks from previous race and how to fix it. When we know (or should to know) an object lifetime - we do nit need raii. When we don't know an object lifetime - we need to fix code and make lifetime predefined, so we also don't need raii. And only in cases when we really need an object with floating lifetime (and mostly with floating ownership) we need to use raii for this particular object type. On Mon, 18 Mar 2024 17:41:47 -0000 Robert Reif via Speed-dreams-devel <spe...@li...> wrote: > I just took a look at fixing #1273. This involves adding a new menu. The menu code is part C and part C++. The menu code passes around void pointers everywhere because of it's C origins and it's use of C function calls. This makes figuring out how the code works difficult. It also make debugging difficult because you don't even know what the void pointer is pointing to. You also have no idea of the lifetime of the data the void pointer points to. I decided to give up on trying to fix this ticket because it's just too hard to figure out all the relationships. This is pretty typical. I'm not against a concrete improvements in places there it will take benefits. But i'm against of "converting just for converting". I've already worked with UI and remember that communication between parts of UI and between UI and game was ugly. But i'm sure that it was not related with C restrictions. I think we need to rework UI to make an immediate mode UI (like: https://immediate-mode-ui.github.io/Nuklear) So we will solve diffrent problems with callbacks and user-pointers associated with buttons and lists items. Because in this types of IU you handle events in the same place where you declare appropriate UI element. It looks like this: void drawUI(UI *ui) { if (uiButton(ui, "help")) showHelp(); uiScrollboxBegin(ui, "tracks", 250, 400); // pass width and height of the scrollbox (track list) for(int i = 0; i < tracksCnt; ++i) if (uiButton(ui, tracks[i].name) startTrack(i); uiScrollboxEnd(ui); if (uiButton(ui, "exit")) doExit(); } icy |
From: Robert R. <io...@us...> - 2024-03-18 17:41:52
|
I just took a look at fixing #1273. This involves adding a new menu. The menu code is part C and part C++. The menu code passes around void pointers everywhere because of it's C origins and it's use of C function calls. This makes figuring out how the code works difficult. It also make debugging difficult because you don't even know what the void pointer is pointing to. You also have no idea of the lifetime of the data the void pointer points to. I decided to give up on trying to fix this ticket because it's just too hard to figure out all the relationships. This is pretty typical. --- **[tickets:#1269] remove plib usage from non-graphics code** **Status:** new **Milestone:** 2.4.0 **Created:** Fri Mar 15, 2024 01:49 AM UTC by Robert Reif **Last Updated:** Mon Mar 18, 2024 03:58 PM UTC **Owner:** nobody **Attachments:** - [t2Dd.diff](https://sourceforge.net/p/speed-dreams/tickets/1269/attachment/t2Dd.diff) (3.6 kB; application/octet-stream) Our interface includes can no longer be used as a C interface because we are including plib C++ template types in them. Since we want to migrate from plib to osg we should start by removing plib dependencies from core non-graphic code. The interface `src/interfaces/track.h` uses a plib type. The attached patch creates an equivalent type in `src/libs/tgf/tgf.h` and uses it. The patch assumes we will no longer try to maintain a C interface. If this approach is acceptable then I will do the same thing to `src/interfaces/car.h`. --- Sent from sourceforge.net because spe...@li... is subscribed to https://sourceforge.net/p/speed-dreams/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/speed-dreams/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Wolf-Dieter B. <wd...@wd...> - 2024-03-18 17:12:24
|
> However, since Speed Dreams' inception (more than 15 years ago), only C++ has been used so far. There was a Delphi Robot and a C# Robot as well. Cheers Wdbee ________________________________ Von: Xavier Del Campo via Speed-dreams-devel <spe...@li...> Gesendet: Montag, 18. März 2024 16:58 An: spe...@li... Cc: Xavier Del Campo Betreff: [Speed-dreams-devel] [speed-dreams:tickets] #1269 remove plib usage from non-graphics code One. Because ABI written at pure C has almost infinite compatibility between any compilers and any verions of compilers. Most of other languages can easy use such ABI directly - pascal, oberon, vala and many others. We or any other can use any of these langs to make AI or renderer. Most of compiled modules are compatible with diffrent versions of the core. This would only make sense if people wrote AI/robots from other programming languages. However, since Speed Dreams' inception (more than 15 years ago), only C++ has been used so far. Therefore, based on experience, it is now far-fetched to expect some random developer to start writing new robots in Oberon, Pascal, Delphi, COBOL or whatever. Since C++ is the only language in use by this project, keeping C ABI-level compatibility is useless. Additionally, I personally think this "shared-libraries-for-everything" model is a clear example of over-engineering that Speed Dreams heavily suffers from. IMHO we should just get rid of it, but I understand this is not a trivial change, so I will not discuss about this topic further for now. Two. The game core sores the current game status in pure C structs that can be eaily serialized. That allow to us abilities to record the game, to rollback the game time just while playing (as like as in StuntRally). We always sure that while editing this data we will not break another game parts. It is also easy to serialise data in C++, and this is definitely not the reason I would choose C over other languages. Moreover, third-party C++ libraries are also available to make it even easier (e.g.: libprotobuf<https://github.com/google/protobuf/>). Three. C makes things as easy as possible. C absolutely does not encourage the creation of extra entities and abstractions. This is not a C project. This is a C++ project. It was not decided by me, or probably anyone else on this discussion, but we cannot revert this decision any more. Disguising a C++ project as a C project is just asking for problems. Again, it does not make any sense to keep ABI compatibility against C because, as far as I can tell, no one is using Speed Dreams from other languages. You are trying to introduce C++ just for C++, just because it is that you've learned. You are very wrong about two things: 1. We are not introducing C++ to Speed Dreams. Speed Dreams is already a C++ project. It stopped being a C project many years ago, probably even from the TORCS days, and cannot be reverted easily now. 2. You seem to know nothing about my background, so let me please correct you. These are some other projects of mine: 3. https://gitea.privatedns.org/xavi/slcl -> a C project 4. https://gitea.privatedns.org/xavi/libweb -> a C project 5. https://gitea.privatedns.org/xavi/nanowasm -> a C project 6. https://gitea.privatedns.org/xavi/dynstr -> a C project 7. https://gitea.privatedns.org/xavi/rts -> a C project 8. https://gitea.privatedns.org/xavi/mkdir_r -> a C project 9. https://gitea.privatedns.org/xavi/jancity -> a C project Can you see the pattern? I can tell you C++ is not the first language I learned first, and also C++ is far from my preferred language list. But Speed Dreams is not a C project. It is a C++ project. C++ it is just a tool than may help and may not. It is not the aim! We could discuss endlessly about how horrible C++ is sometimes, but it will not be useful for anyone at all. Yet again, Speed Dreams is a C++ project, and we must treat it as a C++ project, using best practices. ________________________________ [tickets:#1269]<https://sourceforge.net/p/speed-dreams/tickets/1269/> remove plib usage from non-graphics code Status: new Milestone: 2.4.0 Created: Fri Mar 15, 2024 01:49 AM UTC by Robert Reif Last Updated: Sat Mar 16, 2024 04:01 PM UTC Owner: nobody Attachments: * t2Dd.diff<https://sourceforge.net/p/speed-dreams/tickets/1269/attachment/t2Dd.diff> (3.6 kB; application/octet-stream) Our interface includes can no longer be used as a C interface because we are including plib C++ template types in them. Since we want to migrate from plib to osg we should start by removing plib dependencies from core non-graphic code. The interface src/interfaces/track.h uses a plib type. The attached patch creates an equivalent type in src/libs/tgf/tgf.h and uses it. The patch assumes we will no longer try to maintain a C interface. If this approach is acceptable then I will do the same thing to src/interfaces/car.h. ________________________________ Sent from sourceforge.net because spe...@li... is subscribed to https://sourceforge.net/p/speed-dreams/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/speed-dreams/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: IcyStar <ic...@us...> - 2024-03-18 16:39:55
|
On Mon, 18 Mar 2024 15:58:06 -0000 Xavier Del Campo via Speed-dreams-devel <spe...@li...> wrote: > > One. Because ABI written at pure C has almost infinite compatibility between any compilers and any verions of compilers. Most of other languages can easy use such ABI directly - pascal, oberon, vala and many others. We or any other can use any of these langs to make AI or renderer. Most of compiled modules are compatible with diffrent versions of the core. > > This would only make sense if people wrote AI/robots from other programming languages. However, since Speed Dreams' inception (more than 15 years ago), only C++ has been used so far. Different version of GCC or MSVC has incompatible ABI for C++. > > Two. The game core sores the current game status in pure C structs that can be eaily serialized. That allow to us abilities to record the game, to rollback the game time just while playing (as like as in StuntRally). We always sure that while editing this data we will not break another game parts. > > It is also easy to serialise data in C++, and this is definitely not the reason I would choose C over other languages. Moreover, third-party C++ libraries are also available to make it even easier (e.g.: [`libprotobuf`](https://github.com/google/protobuf/)). If you need thirt-party library then it is not easy. This mean that your methos is more diffcult. > > Three. C makes things as easy as possible. C absolutely does not encourage the creation of extra entities and abstractions. > > This is not a C project. This is a C++ project. It was not decided by me, or probably anyone else on this discussion, but we cannot revert this decision any more. Disguising a C++ project as a C project is just asking for problems. Is C++ the aim? Is is not a tool, is it the aim? > > You are trying to introduce C++ just for C++, just because it is that you've learned. > > You are very wrong about two things: > > 1. We are not introducing C++ to Speed Dreams. Speed Dreams **is already** a C++ project. It stopped being a C project many years ago, probably even from the TORCS days, and cannot be reverted easily now. If it was "already" then why you want to convert something? You just want to change the code to make it more C++. And you think that reason is not required for thin changes. > 2. You seem to know nothing about my background, so let me please correct you. These are some other projects of mine: Is it really has meaning? I may say in other words: because you've learned that making all in classes, tempalates and references is the best choice ever. > > C++ it is just a tool than may help and may not. It is not the aim! > > We could discuss endlessly about how horrible C++ is sometimes, but it will not be useful for anyone at all. Yet again, Speed Dreams is a C++ project, and we must treat it as a C++ project, using best practices. C99 is a part of C++. Trivial structs and classes also part of C++. Standalone functions and pointers also part of C++. We have all of these tools and must consider all of them while choosing the best solution for concrete tasks. Changes of the code should be dictated by real usefulness and necessity. And this usefulness must be indicated. And this is exactly what you need to talk about, instead of saying “let’s rework this to C++”. As if the "reworking to C++" itself is the most beautiful thing in the world. icy --- **[tickets:#1269] remove plib usage from non-graphics code** **Status:** new **Milestone:** 2.4.0 **Created:** Fri Mar 15, 2024 01:49 AM UTC by Robert Reif **Last Updated:** Mon Mar 18, 2024 03:58 PM UTC **Owner:** nobody **Attachments:** - [t2Dd.diff](https://sourceforge.net/p/speed-dreams/tickets/1269/attachment/t2Dd.diff) (3.6 kB; application/octet-stream) Our interface includes can no longer be used as a C interface because we are including plib C++ template types in them. Since we want to migrate from plib to osg we should start by removing plib dependencies from core non-graphic code. The interface `src/interfaces/track.h` uses a plib type. The attached patch creates an equivalent type in `src/libs/tgf/tgf.h` and uses it. The patch assumes we will no longer try to maintain a C interface. If this approach is acceptable then I will do the same thing to `src/interfaces/car.h`. --- Sent from sourceforge.net because spe...@li... is subscribed to https://sourceforge.net/p/speed-dreams/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/speed-dreams/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: <bh...@ic...> - 2024-03-18 16:39:53
|
On Mon, 18 Mar 2024 15:58:06 -0000 Xavier Del Campo via Speed-dreams-devel <spe...@li...> wrote: > > One. Because ABI written at pure C has almost infinite compatibility between any compilers and any verions of compilers. Most of other languages can easy use such ABI directly - pascal, oberon, vala and many others. We or any other can use any of these langs to make AI or renderer. Most of compiled modules are compatible with diffrent versions of the core. > > This would only make sense if people wrote AI/robots from other programming languages. However, since Speed Dreams' inception (more than 15 years ago), only C++ has been used so far. Different version of GCC or MSVC has incompatible ABI for C++. > > Two. The game core sores the current game status in pure C structs that can be eaily serialized. That allow to us abilities to record the game, to rollback the game time just while playing (as like as in StuntRally). We always sure that while editing this data we will not break another game parts. > > It is also easy to serialise data in C++, and this is definitely not the reason I would choose C over other languages. Moreover, third-party C++ libraries are also available to make it even easier (e.g.: [`libprotobuf`](https://github.com/google/protobuf/)). If you need thirt-party library then it is not easy. This mean that your methos is more diffcult. > > Three. C makes things as easy as possible. C absolutely does not encourage the creation of extra entities and abstractions. > > This is not a C project. This is a C++ project. It was not decided by me, or probably anyone else on this discussion, but we cannot revert this decision any more. Disguising a C++ project as a C project is just asking for problems. Is C++ the aim? Is is not a tool, is it the aim? > > You are trying to introduce C++ just for C++, just because it is that you've learned. > > You are very wrong about two things: > > 1. We are not introducing C++ to Speed Dreams. Speed Dreams **is already** a C++ project. It stopped being a C project many years ago, probably even from the TORCS days, and cannot be reverted easily now. If it was "already" then why you want to convert something? You just want to change the code to make it more C++. And you think that reason is not required for thin changes. > 2. You seem to know nothing about my background, so let me please correct you. These are some other projects of mine: Is it really has meaning? I may say in other words: because you've learned that making all in classes, tempalates and references is the best choice ever. > > C++ it is just a tool than may help and may not. It is not the aim! > > We could discuss endlessly about how horrible C++ is sometimes, but it will not be useful for anyone at all. Yet again, Speed Dreams is a C++ project, and we must treat it as a C++ project, using best practices. C99 is a part of C++. Trivial structs and classes also part of C++. Standalone functions and pointers also part of C++. We have all of these tools and must consider all of them while choosing the best solution for concrete tasks. Changes of the code should be dictated by real usefulness and necessity. And this usefulness must be indicated. And this is exactly what you need to talk about, instead of saying “let’s rework this to C++”. As if the "reworking to C++" itself is the most beautiful thing in the world. icy |
From: Xavier D. C. <xa...@us...> - 2024-03-18 15:58:06
|
> One. Because ABI written at pure C has almost infinite compatibility between any compilers and any verions of compilers. Most of other languages can easy use such ABI directly - pascal, oberon, vala and many others. We or any other can use any of these langs to make AI or renderer. Most of compiled modules are compatible with diffrent versions of the core. This would only make sense if people wrote AI/robots from other programming languages. However, since Speed Dreams' inception (more than 15 years ago), only C++ has been used so far. Therefore, based on experience, it is now far-fetched to expect some random developer to start writing new robots in Oberon, Pascal, Delphi, COBOL or whatever. Since C++ is the only language in use by this project, keeping C ABI-level compatibility is useless. Additionally, I personally think this "shared-libraries-for-everything" model is a clear example of over-engineering that Speed Dreams heavily suffers from. IMHO we should just get rid of it, but I understand this is not a trivial change, so I will not discuss about this topic further for now. > Two. The game core sores the current game status in pure C structs that can be eaily serialized. That allow to us abilities to record the game, to rollback the game time just while playing (as like as in StuntRally). We always sure that while editing this data we will not break another game parts. It is also easy to serialise data in C++, and this is definitely not the reason I would choose C over other languages. Moreover, third-party C++ libraries are also available to make it even easier (e.g.: [`libprotobuf`](https://github.com/google/protobuf/)). > Three. C makes things as easy as possible. C absolutely does not encourage the creation of extra entities and abstractions. This is not a C project. This is a C++ project. It was not decided by me, or probably anyone else on this discussion, but we cannot revert this decision any more. Disguising a C++ project as a C project is just asking for problems. Again, it does not make any sense to keep ABI compatibility against C because, as far as I can tell, no one is using Speed Dreams from other languages. > You are trying to introduce C++ just for C++, just because it is that you've learned. You are very wrong about two things: 1. We are not introducing C++ to Speed Dreams. Speed Dreams **is already** a C++ project. It stopped being a C project many years ago, probably even from the TORCS days, and cannot be reverted easily now. 2. You seem to know nothing about my background, so let me please correct you. These are some other projects of mine: - https://gitea.privatedns.org/xavi/slcl -> a C project - https://gitea.privatedns.org/xavi/libweb -> a C project - https://gitea.privatedns.org/xavi/nanowasm -> a C project - https://gitea.privatedns.org/xavi/dynstr -> a C project - https://gitea.privatedns.org/xavi/rts -> a C project - https://gitea.privatedns.org/xavi/mkdir_r -> a C project - https://gitea.privatedns.org/xavi/jancity -> a C project Can you see the pattern? I can tell you C++ is not the first language I learned first, and also C++ is far from my preferred language list. But Speed Dreams is *not* a C project. It is a C++ project. > C++ it is just a tool than may help and may not. It is not the aim! We could discuss endlessly about how horrible C++ is sometimes, but it will not be useful for anyone at all. Yet again, Speed Dreams is a C++ project, and we must treat it as a C++ project, using best practices. --- **[tickets:#1269] remove plib usage from non-graphics code** **Status:** new **Milestone:** 2.4.0 **Created:** Fri Mar 15, 2024 01:49 AM UTC by Robert Reif **Last Updated:** Sat Mar 16, 2024 04:01 PM UTC **Owner:** nobody **Attachments:** - [t2Dd.diff](https://sourceforge.net/p/speed-dreams/tickets/1269/attachment/t2Dd.diff) (3.6 kB; application/octet-stream) Our interface includes can no longer be used as a C interface because we are including plib C++ template types in them. Since we want to migrate from plib to osg we should start by removing plib dependencies from core non-graphic code. The interface `src/interfaces/track.h` uses a plib type. The attached patch creates an equivalent type in `src/libs/tgf/tgf.h` and uses it. The patch assumes we will no longer try to maintain a C interface. If this approach is acceptable then I will do the same thing to `src/interfaces/car.h`. --- Sent from sourceforge.net because spe...@li... is subscribed to https://sourceforge.net/p/speed-dreams/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/speed-dreams/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: June H. R. <har...@us...> - 2024-03-18 14:38:07
|
Added some context since this is only true for initial event setup. Once actually in an event I can't change my car's setup between sessions. --- **[tickets:#1273] No setup menu for multi-session game modes between sessions** **Status:** new **Milestone:** 2.4.0 **Labels:** setup championship robots human cars **Created:** Mon Mar 18, 2024 05:39 AM UTC by June "Haruna" Ravenmoon **Last Updated:** Mon Mar 18, 2024 02:36 PM UTC **Owner:** nobody In any game type that has more than one session, such as in Challenge, Championship, or Endurance, there are no menu options for players to make setup changes between sessions (ie. from Qualifying to Main Race) --- Sent from sourceforge.net because spe...@li... is subscribed to https://sourceforge.net/p/speed-dreams/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/speed-dreams/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |