crashes when entering clan screen

the game crashes the 1st time you enter your clan screen
Mod Version

Standard
Numeric Version: <IP_ADDRESS>

Evidence

[x] The mod is present in the callstack;
[x] The issue only happens with the mod activated;
[x] You tested it with the least amount of other mods as possible.
I've tested the it with only banner kings active
Crash Report
at BannerKings.UI.Items.BKItemVM..ctor(Int32 index, Boolean isAvailable, TextObject hint, TextObject name)
at BannerKings.UI.Court.CouncilPositionVM..ctor(CouncilMember position, Action1 setId, Action1 updatePosition)
at BannerKings.UI.Court.CourtVM.RefreshValues()
at BannerKings.UI.Extensions.ClanManagementMixin.OnRefresh()
at Bannerlord.UIExtenderEx.Patches.ViewModelWithMixinPatch.Constructor(ViewModel viewModel, String _)
at TaleWorlds.CampaignSystem.ViewModelCollection.ClanManagement.ClanManagementVM..ctor_Patch0(ClanManagementVM this, Action onClose, Action1 showHeroOnMap, Action1 openPartyAsManage, Action openBannerEditor)
at SandBox.GauntletUI.GauntletClanScreen.TaleWorlds.Core.IGameStateListener.OnActivate()
at TaleWorlds.Core.GameState.HandleActivate()
at TaleWorlds.Core.GameStateManager.OnPushState(GameState gameState)
at TaleWorlds.Core.GameStateManager.DoGameStateJobs()
at TaleWorlds.Core.GameStateManager.PushState(GameState gameState, Int32 level)
at SandBox.View.Map.MapNavigationHandler.PrepareToOpenClanScreen(Action openClanScreenAction)Outer exception callstack:
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at TaleWorlds.Library.Common.InvokeWithLog(MethodInfo methodInfo, Object obj, Object[] args)
at TaleWorlds.Library.ViewModel.ExecuteCommand_Patch1(ViewModel this, String commandName, Object[] parameters)
at TaleWorlds.GauntletUI.Data.GauntletView.OnCommand(String command, Object[] args)
at TaleWorlds.GauntletUI.BaseTypes.Widget.EventFired(String eventName, Object[] args)
at TaleWorlds.GauntletUI.BaseTypes.ButtonWidget.HandleClick()
at TaleWorlds.GauntletUI.BaseTypes.ButtonWidget.OnMouseReleased()
at TaleWorlds.GauntletUI.EventManager.MouseUp()
at TaleWorlds.GauntletUI.UIContext.UpdateInput(InputType handleInputs)
at TaleWorlds.ScreenSystem.ScreenManager.Update()
at TaleWorlds.ScreenSystem.ScreenManager.Tick_Patch1(Single dt, Boolean activeMouseVisible)

Can confirm this is the case.
Tried it with only bannerlord and required mods, upon new campaign or sandbox it crashes upon going to clan page.
I have been able to circumvent this by starting a new campaign with the previous version, opening the clan page, then saving, then swapping with the new version. Upon loading the save with the updated bannerlord it does not crash. Will report if it happens in the future again.

Can confirm this is the case. Tried it with only bannerlord and required mods, upon new campaign or sandbox it crashes upon going to clan page.
I have been able to circumvent this by starting a new campaign with the previous version, opening the clan page, then saving, then swapping with the new version. Upon loading the save with the updated bannerlord it does not crash. Will report if it happens in the future again.

Sounds like an initialization problem. Like in the new version it's calling for something it hasn't generated yet and flakes out because of it.

Can confirm this is the case. Tried it with only bannerlord and required mods, upon new campaign or sandbox it crashes upon going to clan page.
I have been able to circumvent this by starting a new campaign with the previous version, opening the clan page, then saving, then swapping with the new version. Upon loading the save with the updated bannerlord it does not crash. Will report if it happens in the future again.

So do you mean game version or the BannerKing Version , thank you

I mean the Banner Kings version, going from 1.2.7 to <IP_ADDRESS>

So do you mean game version or the BannerKing Version , thank you

I mean the Banner Kings version, going from 1.2.7 to <IP_ADDRESS>

Okay thank you I shall do the same is everything still running smooth for you?

So do you mean game version or the BannerKing Version , thank you

I mean the Banner Kings version, going from 1.2.7 to <IP_ADDRESS>

Okay thank you I shall do the same is everything still running smooth for you?

Yup, haven't had any problems, joined a kingdom and everything is going without any issue.


Consider evaluation of expression on destruction;

Would it be possible to evaluate (by default or as an option) to evaluate expression upon destruction.
For example, normally in expression template libraries, one has some sort of evaluate function,
terminal a = ...
terminal b = ...
terminal c = ...
evaluate(a = b + c);

In principle, destruction on ; could trigger the evaluation.
a = b + c;

I think it is possible to do because subexpression could be flagged not to evaluate upon their destruction.
Another example from hello_world:
#include <boost/yap/expression.hpp>
#include <iostream>
int main (){
//traditional:
// evaluate(boost::yap::make_terminal(std::cout) << "Hello" << ',' << " world!\n");
// automatic evaluation on destruction of a temporary
    boost::yap::make_terminal(std::cout) << "Hello" << ',' << " world!\n";
// or at least:
//    boost::yap::make_auto_terminal(std::cout) << "Hello" << ',' << " world!\n";
    return 0;
}

This way the syntax will be more natural.
What do you think?

For now, I'm against this approach.  I think evaluations (and transforms) should be explicit.  While the "_auto" add to make_terminal() might technically count as explicit, I think many users' eyes would jump right past that.

Perhaps after our discussion on cppnow you might want to reconsider this. Perhaps I didn't word it well on the original issue post.

Yes, absolutely.  I have this on my TODO list now.  Thanks again for
bringing it up.
Zach
On Wed, May 8, 2019, 5:25 AM Alfredo Correa<EMAIL_ADDRESS>wrote:

Perhaps after our discussion on cppnow you might want to reconsider this.
Perhaps I didn't word it well on the original issue post.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/boostorg/yap/issues/26#issuecomment-490449424, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAUCAKNTYVGYNAOAKLCPNLPUK2D5ANCNFSM4D2HGIFA
.

Ok, the new example is ready; you're looking for the "Self-evaluating Expressions" exsample:
https://www.boost.org/doc/libs/develop/doc/html/yap.html
This should appear in the next Boost release.

Absolutely amazing, this is exact case (axpy) was the first thing I wanted to do the first time I used YAP.
In principle in the hypothetical conceptual code
matrix m1{...}, m2{...}, m3{...};
m1 = 3.0 * m2 + m3;

The only part that needs to be explicitly yapified (am I using it right?) is m2 to trigger full control over the expression behavior (including the assignment). no?
m1 = 3.0 * expr(m2) + m3;

Yes, that will do it.  If there is an optimization that applies to the left-hand side, though, you'd want to do:
expr(m1) = 3.0 * expr(m2) + m3;
In other words, you'd want to YAP-ifiy m1 too, so that the entire assignment is captured as a transformable, optimizable expression.

well, that if somehow© 3.0*expr(m2) + m3 is not implicitly convertible
(self evaluable) to the matrix type.
On Fri, May 31, 2019 at 11:42 AM Zach Laine<EMAIL_ADDRESS>wrote:

Yes, that will do it. If there is an optimization that applies to the
left-hand side, though, you'd want to do:
expr(m1) = 3.0 * expr(m2) + m3;
In other words, you'd want to YAP-ifiy m1 too, so that the entire
assignment is captured as a transformable, optimizable expression.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/boostorg/yap/issues/26?email_source=notifications&email_token=AAXICU4F6Y4QI5Y3JAVN7T3PYFWRNA5CNFSM4D2HGIFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWWB5CQ#issuecomment-497819274,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXICUZE2VOHSQWI56CIIZLPYFWRNANCNFSM4D2HGIFA
.

On Fri, May 31, 2019 at 1:04 PM Alfredo Correa<EMAIL_ADDRESS>wrote:

well, that if somehow© 3.0*expr(m2) + m3 is not implicitly convertible
(self evaluable) to the matrix type.

Can one make m1 = 3.0*expr(m2) + m3 within the library, or after a
minimal extension.

On Fri, May 31, 2019 at 11:42 AM Zach Laine<EMAIL_ADDRESS>wrote:

Yes, that will do it. If there is an optimization that applies to the
left-hand side, though, you'd want to do:
expr(m1) = 3.0 * expr(m2) + m3;
In other words, you'd want to YAP-ifiy m1 too, so that the entire
assignment is captured as a transformable, optimizable expression.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/boostorg/yap/issues/26?email_source=notifications&email_token=AAXICU4F6Y4QI5Y3JAVN7T3PYFWRNA5CNFSM4D2HGIFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWWB5CQ#issuecomment-497819274,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXICUZE2VOHSQWI56CIIZLPYFWRNANCNFSM4D2HGIFA
.

I don't really understand the question.  You just "made" m1 = 3.0*expr(m2) + m3 within the question itself, didn't you?  I don't really get what you're asking.

Sorry, the word "work" after the code was missing.
matrix m1; m1 = 3.0*expr(m2) + m3.
Where matrix is a concrete matrix not an expression. Types in the expression somehow imply the need for an evaluation on the rhs.

Yes, that works.  That's covered in the example by the operator auto() const conversion operator on the primary expression template.
One other way you could accomplish this, that I did not show in the example, would be to add a templated ctor to the matrix type:
struct matrix {
    template <typename Expr>
    matrix (Expr && expr) {
        // Might be better expressed via SFINAE or via concept.
        static_assert(boost::yap::is_expr<Expr>::value, "a YAP expression is required");
        *this = optimize_and_evaluate(expr);
    }
    // ...
};


Class "Site" irrelevant?

In this information model, there is a class called Site used for modelling websites. It has exactly one property: ids:siteAddress (string).
However, the homepage and the corporate homepage of a participant are Datatype Properties, pointing directly to xsd:anyURI and not using the Site class at all. The "primary site" property of a participant is an Object Property, pointing to a Site object.
As the Site class only stores an address (which should be a URI, not a string), I would suggest removing this class and making ids:primarySite point to anyURI instead.
See here: https://github.com/IndustrialDataSpace/InformationModel/blob/develop/model/participant/Participant.ttl#L55

I think the naming is a bit confusing.  I assume ids:Site should be used for a Participants address, e.g., office address of a company. See the corresponding documentation for org:Site, which is a superclass of ids:Site.
An enhancement could be a more fine-grained approach to model an address. Therefore rdfs:range of ìds:siteAddress` could for example reference the v-card ontology, but I'm ok with range xsd:string for now.
A RDF example in Turtle pseudocode, how the class should be used (in my understanding)
fraunhofer_foo a ids:Participant
    ids:corperateEmailAddress<EMAIL_ADDRESS>(string)
    ids:corporateHomepage`  _"http://foo.fraunhofer.de"_ (URI)
    ids:primarySite [ a ids:Site
        ids:siteAdress    "Fraunhofer Foo
                           Street 1
                           12345 Town
                           Germany"
                                ]

Ahh, thanks for clarification. My bad :)


1.1.0 beta1: Personal message labels are not stored

While logged in and at /index.php?action=pm;sa=manlabels, where I should be able to manage personal message labels, when I try to add / define a new label, nothing is stored, no warning message is printed and no error message is logged. But the label is not created either.
It would seem that this functionality is broken in this beta.

Would you mind checking in the database (table messages) if the field (message_labels) is populated?

There is no such field ("%label%") in the "messages" table:
CREATE TABLE `messages` (
  `id_msg` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `id_topic` mediumint(8) unsigned NOT NULL DEFAULT '0',
  `id_board` smallint(5) unsigned NOT NULL DEFAULT '0',
  `poster_time` int(10) unsigned NOT NULL DEFAULT '0',
  `id_member` mediumint(8) unsigned NOT NULL DEFAULT '0',
  `id_msg_modified` int(10) unsigned NOT NULL DEFAULT '0',
  `subject` varchar(255) NOT NULL DEFAULT '',
  `poster_name` varchar(255) NOT NULL DEFAULT '',
  `poster_email` varchar(255) NOT NULL DEFAULT '',
  `poster_ip` varchar(255) NOT NULL DEFAULT '',
  `smileys_enabled` tinyint(4) NOT NULL DEFAULT '1',
  `modified_time` int(10) unsigned NOT NULL DEFAULT '0',
  `modified_name` varchar(255) NOT NULL DEFAULT '',
  `body` text NOT NULL,
  `icon` varchar(16) NOT NULL DEFAULT 'xx',
  `approved` tinyint(3) NOT NULL DEFAULT '1',
  PRIMARY KEY (`id_msg`),
  UNIQUE KEY `topic` (`id_topic`,`id_msg`),
  UNIQUE KEY `id_board` (`id_board`,`id_msg`),
  UNIQUE KEY `id_member` (`id_member`,`id_msg`),
  KEY `approved` (`approved`),
  KEY `ip_index` (`poster_ip`(15),`id_topic`),
  KEY `participation` (`id_member`,`id_topic`),
  KEY `show_posts` (`id_member`,`id_board`),
  KEY `id_topic` (`id_topic`),
  KEY `id_member_msg` (`id_member`,`approved`,`id_msg`),
  KEY `current_topic` (`id_topic`,`id_msg`,`id_member`,`approved`),
  KEY `related_ip` (`id_member`,`poster_ip`,`id_msg`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Sorry, the usual problem: I think members and type messages and vice versa...
It's the {db_prefix}members table.

For the one (single) user I have there currently, it seems to be an empty string (but I did not try to hex dump it - let me know if you want me to).

I have to start a fresh install, it's working fine on the testing board, but it's one I use since forever, so it may have something odd.

Just wanted to say, I can confirm that it still works on 1.0.7 and freshly installed 1.1.0 beta1

To sum it up:
For some reason (which we have not yet determined) my fresh install of 1.1.0 beta1 lacks, in DB table messages table, the field message_labels, which is expected to exist on a fresh install.
h-collector, however, reports that the functionality which depends on this table works for him.
@h-collector: Can we see the SQL scheme of the messages table of your fresh 1.1.0 beta1 installation, so we can compare the two?
If you like to work on the shell use this command against your database MY_ELKARTE_DB:
echo 'describe messages \G' | mysql MY_ELKARTE_DB | grep -B1 -A5 'Field: .*message.*$'

in DB table messages table

It's the members table! ;)

Oh right sorry, my bad. So we are talking about this table:

CREATE TABLE `members` (
  `id_member` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
  `member_name` varchar(80) NOT NULL DEFAULT '',
  `date_registered` int(10) unsigned NOT NULL DEFAULT '0',
  `posts` mediumint(8) unsigned NOT NULL DEFAULT '0',
  `id_group` smallint(5) unsigned NOT NULL DEFAULT '0',
  `lngfile` varchar(255) NOT NULL DEFAULT '',
  `last_login` int(10) unsigned NOT NULL DEFAULT '0',
  `real_name` varchar(255) NOT NULL DEFAULT '',
  `personal_messages` mediumint(8) NOT NULL DEFAULT '0',
  `mentions` smallint(5) NOT NULL DEFAULT '0',
  `unread_messages` smallint(5) NOT NULL DEFAULT '0',
  `new_pm` tinyint(3) unsigned NOT NULL DEFAULT '0',
  `buddy_list` text NOT NULL,
  `pm_ignore_list` varchar(255) NOT NULL DEFAULT '',
  `pm_prefs` mediumint(8) NOT NULL DEFAULT '2',
  `mod_prefs` varchar(20) NOT NULL DEFAULT '',
  `message_labels` text NOT NULL,
  `passwd` varchar(64) NOT NULL DEFAULT '',
  `openid_uri` text NOT NULL,
  `email_address` varchar(255) NOT NULL DEFAULT '',
  `birthdate` date NOT NULL DEFAULT '0001-01-01',
  `website_title` varchar(255) NOT NULL DEFAULT '',
  `website_url` varchar(255) NOT NULL DEFAULT '',
  `hide_email` tinyint(4) NOT NULL DEFAULT '0',
  `show_online` tinyint(4) NOT NULL DEFAULT '1',
  `time_format` varchar(80) NOT NULL DEFAULT '',
  `signature` text NOT NULL,
  `time_offset` float NOT NULL DEFAULT '0',
  `avatar` varchar(255) NOT NULL DEFAULT '',
  `pm_email_notify` tinyint(4) NOT NULL DEFAULT '0',
  `karma_bad` smallint(5) unsigned NOT NULL DEFAULT '0',
  `karma_good` smallint(5) unsigned NOT NULL DEFAULT '0',
  `likes_given` mediumint(5) unsigned NOT NULL DEFAULT '0',
  `likes_received` mediumint(5) unsigned NOT NULL DEFAULT '0',
  `usertitle` varchar(255) NOT NULL DEFAULT '',
  `notify_announcements` tinyint(4) NOT NULL DEFAULT '1',
  `notify_regularity` tinyint(4) NOT NULL DEFAULT '1',
  `notify_send_body` tinyint(4) NOT NULL DEFAULT '0',
  `notify_types` tinyint(4) NOT NULL DEFAULT '2',
  `member_ip` varchar(255) NOT NULL DEFAULT '',
  `member_ip2` varchar(255) NOT NULL DEFAULT '',
  `secret_question` varchar(255) NOT NULL DEFAULT '',
  `secret_answer` varchar(64) NOT NULL DEFAULT '',
  `id_theme` tinyint(4) unsigned NOT NULL DEFAULT '0',
  `is_activated` tinyint(3) unsigned NOT NULL DEFAULT '1',
  `validation_code` varchar(10) NOT NULL DEFAULT '',
  `id_msg_last_visit` int(10) unsigned NOT NULL DEFAULT '0',
  `additional_groups` varchar(255) NOT NULL DEFAULT '',
  `smiley_set` varchar(48) NOT NULL DEFAULT '',
  `id_post_group` smallint(5) unsigned NOT NULL DEFAULT '0',
  `total_time_logged_in` int(10) unsigned NOT NULL DEFAULT '0',
  `password_salt` varchar(255) NOT NULL DEFAULT '',
  `ignore_boards` text NOT NULL,
  `warning` tinyint(4) NOT NULL DEFAULT '0',
  `passwd_flood` varchar(12) NOT NULL DEFAULT '',
  `receive_from` tinyint(4) unsigned NOT NULL DEFAULT '1',
  `otp_secret` varchar(16) NOT NULL DEFAULT '',
  `enable_otp` tinyint(1) NOT NULL DEFAULT '0',
  `otp_used` int(6) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id_member`),
  KEY `member_name` (`member_name`),
  KEY `real_name` (`real_name`),
  KEY `date_registered` (`date_registered`),
  KEY `id_group` (`id_group`),
  KEY `birthdate` (`birthdate`),
  KEY `posts` (`posts`),
  KEY `last_login` (`last_login`),
  KEY `lngfile` (`lngfile`(30)),
  KEY `id_post_group` (`id_post_group`),
  KEY `warning` (`warning`),
  KEY `total_time_logged_in` (`total_time_logged_in`),
  KEY `id_theme` (`id_theme`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

I just retried with all of the security HTTP headers disabled (and the web server restarted), on two different web browsers, after deleting any cached settings, and am still unable to add a new message label.

@tomreyn there is message_labels ;)
1.0.7/1.1.0 beta1 same:
members (59 fields in total)
*************************** 17. row ***************************
  Field: message_labels
   Type: text
   Null: NO
    Key:
Default: NULL
  Extra:

pm_recipients
*************************** 3. row ***************************
  Field: labels
   Type: varchar(60)
   Null: NO
    Key:
Default: -1
  Extra:

So those look very much the same.
For what it's worth, I just tried adding labels on elkarte.net/community and I can confirm it works there. It doe snot work on my installation, though, and I do not understand why that is.

Could you check the html of the page to see if by any chance some tag is not properly open/close and breaks the form? (Not using the various inspect, but a good old ctrl+u)

@tomreyn Could you also check Request (POST) params, they should look something like

followed by 302 redirection
PS. @emanuele45 should duplicated labels be allowed (enhancement)? That is, it looks kinda weird :)

Yes, that's exactly what it looks like here, too.
Request #1:
POST https://FORUM_FQDN/index.php?action=pm;sa=manlabels

Host: FORUM_FQDN
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://FORUM_FQDN/index.php?action=pm;sa=manlabels
Cookie: PHPSESSID=[REDACTED]; ElkArteCookie[REDACTED]=[REDACTED]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 76

label=thisisnew&add=Add+new+label&[REDACTED]=[REDACTED]

Cache-Control: private
Connection: keep-alive
Content-Type: text/html; charset=UTF-8
Date: Mon, 04 Jul 2016 19:42:26 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive: timeout=20
Location: https://FORUM_FQDN/index.php?action=pm;sa=manlabels
Pragma: no-cache
Server: Nginx
Transfer-Encoding: chunked
X-Frame-Options: SAMEORIGIN
x-content-type-options: nosniff
x-xss-protection: 1

Request #2:
GET https://FORUM_FQDN/index.php?action=pm;sa=manlabels

Host: FORUM_FQDN
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://FORUM_FQDN/index.php?action=pm;sa=manlabels
Cookie: PHPSESSID=[REDACTED]; ElkArteCookie[REDACTED]=[REDACTED]
Connection: keep-alive

Cache-Control: private
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html; charset=UTF-8
Date: Mon, 04 Jul 2016 19:42:26 GMT
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Keep-Alive: timeout=20
Last-Modified: Mon, 04 Jul 2016 19:42:26 GMT
Pragma: no-cache
Server: Nginx
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Frame-Options: SAMEORIGIN
x-content-type-options: nosniff
x-xss-protection: 1

Further testing turns out it is an opcode caching issue. With the APCU and recommended caching level 1, the newly configured label is actually written to the database, but the page is not updated even on shift-reload.
Disabling the opcode caching option in the admin area and deleting the cache makes it work as expected. Since APC(U) is listed as supported and caching is set to the recommended level, I guess we can consider this a bug.

Great catch @tomreyn !!
 LOL
And our caching has some issues here and there... :grin:

Then, most likely, this will affect 1.0 as well...
I'll dig into the fix and in case apply it to 1.0 line first.

I was looking at that one, but I'm not 100% sure how it happens.
In theory users data are cached only if the cache level is 2+, so I'm not sure how cache may be a factor here.
Would you mind trying with an higher level of cache?

I can reproduce the issue any of the caching levels with this APC(U) cache.
You say you're not sure how it happens - were you able to reproduce it, though, or did you try to reproduce it but could not, or do you not have a suitable test environment available to test this specific configuration on?

Then I guess I'm looking at the wrong code...
No, I didn't actually test because I tend not to mess with accelerators (sorry, I'm terrible at configuring even simple stuff, I write code and do the basic sysadmin, but already configure relatively simple stuff can be overwhelming for me :sob: ), I was following code to see where the issue seemed to be, I didn't meant to say the problem was not there, but just that looking at the code it seemed "right" (i.e. the cache is built and then cleaned), but likely it is re-built or reused somewhere else and the net result is the label value not being loaded properly.
Another thing, could you try with another cache? For example file-based?

For 1.0.7 seems to work fine on all 3 levels of cache:
Remote VPS:
PHP: 5.6.23-2+deb.sury.org~trusty+1
Zend OPcache: v7.0.6-dev
APC(U): 4.0.11
NGINX: 1.4.6
Local builtin server:
PHP: 7.0.8-3 file-based cache
PHP: 5.6.23-2 file-based cache
As for v1-1-0-beta1, I can confirm that it really does not work on any 3 levels:
Local builtin server:
PHP: 7.0.8-3 file-based cache (storing don't work)
PHP: 5.6.23-2 file-based cache (storing don't work)


add doc comments for storage_context module

Need to update the documents.

Need to update the documents.

done.

Why so many document updates?

I simply ran this command (rooch doc docgen) in the current directory, need to specify a file right?

run the genesis build to generate doc.


Copy .editorconfig from dotnet/corefx repo

This repo should adhere to the coding guidlines defined in https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/coding-style.md. Assuming their .editorconfig exactly captures these guidelines, they have been copied here.

Is there a way to have a list of nonconforming files and lines or it is required to open each .cs file?

Investigating. So far I didn't find a way to scan the whole sln, however, ReSharper understands .editorconfig as well and is able to perform a full scan.

I'm working on adding unit tests that verify the recent changes in components based on code coverage. I don't plan to change anything other than tests.

We do not need to follow their rules explicitly. Many of them sure, but for others like var, we don't need to be as strict as them. I'd go the other way and say we should always use var.

It will probably create impossible cases, for example:

If you have var you have to default it to some type, which by definition will be ignored. Having IDisposable[] previousDisposable; will complain about not using var.

So, is there anything we definitely want to take from the corefx-config? We might as well settle with the original config or enhance that.

@onovotny We have settled on some changed. Do you think we can go with the proposed .editorconfig?

Looks good, the only suggestion I would add is to specify yaml/yml as indent size of 2. Otherwise, LGTM.

@onovotny Can you access the build-logs? I can't, that has been happening occasionally for a while now.

I don't see the logs either but am looking into it via other avenues.


experimental.scanPageMeta breaks non-vue pages

Environment

Operating System: Darwin
Node Version:     v20.12.2
Nuxt Version:     3.13.2
CLI Version:      3.14.0
Nitro Version:    2.9.7
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      -
Runtime Modules:  -
Build Modules:    -

Reproduction
https://github.com/nuxt-modules/compile-markdown/blob/07c99b0e7362cbb6c0efa8bc6dc6a105a92cc0bb/playground/nuxt.config.ts#L18
Describe the bug
The experimental.scanPageMeta flag breaks https://github.com/nuxt-modules/compile-markdown, there it supports files like pages/foo.md, with a transformation to generated definePageMeta in the generated code (https://github.com/nuxt-modules/compile-markdown/blob/07c99b0e7362cbb6c0efa8bc6dc6a105a92cc0bb/src/module.ts#L133). It was able to extra the meta when experimental.scanPageMeta is disable - maybe we should allow fallbacks for files that not parsable as Vue file on scanning?
Creating this quick issue to keep track. I can also look into it later.
Additional context
No response
Logs
No response

cc @BobbieGoede

if we fail gracefully, that should be good enough, right?

I guess it would be more like an optimization? The original ?marco seems still work at runtime, I guess if could just fallback to the runtime one when didn't get the result from scanning?


Initialize fields outside of init block for better readability

I have to resolve some merge conflicts.
Shall I enable compass, finance, invoice and source while I'm at it, or is there a specific reason they are commented out?

I have to resolve some merge conflicts.
Shall I enable compass, finance, invoice and source while I'm at it, or is there a specific reason they are commented out?

Sorry, I completely missed your last comment. They were (are) commented out because they're currently not implemented, so I don't really see a point to have a provider like finance in Faker that does not provide any working functions.


Local Copy Not Saved When Phone Dies

There have been many times I've done a long stream and run my battery down to the point where it dies
When this happens, the local copy ends up trashed.  I end up with a 2+ GB file, that I cannot open in any external app
My asks:

Is there a way to open / fix / restore / salvage / extract video from these incomplete files that weren't ended properly?
Can you implement a feature that either: a) creates videos that don't need to be finalized, or b) stops and saves the video when the phone battery is critically low?

Thanks!

We can see your message to our helpdesk about this so we'll respond there. Thank you.


Autorotate and updateFile, generated thumbnail uses old metadata

I really love Sharp for image manipulation, but the thumnbail size is incorrect when generating it after updating a file on disk. When restarting node and generating the thumbnail again, the same code behaves correctly.
Steps to reproduce

autorotate a file based on the exif information (source file has exif orientation 6, portrait picture)
save the autorotated file to the original path
generate a thumbnail

For steps 1 and 2, I first tried following command:
sharp(obj.path).rotate().toFile(obj.path);
However, this throws following error:
Cannot use same file for input and output
I successfully changed this code to update the file on disk using fs:
sharp(obj.path).rotate().toBuffer().then(
  function (buffer) {
    return new Promise(function (resolve, reject) {
      // Write buffer
      fs.writeFile(obj.path, buffer, function (err) {
        if (err) {
          reject(err);
        } else {
          sharp(obj.path).metadata().then(
            function (meta) {
              // Update the metadata (with and height have switched)
              obj.meta = meta;

              // Resolve with the object
              resolve(obj);
            }
          ).catch(
            function (err) {
              reject(err);
            }
          );
        }
      });
    });
  }
);

Next, step 3: resize this image to a width of 1000px and output it to a browser:
sharp(path).resize(1000, null, {}).toBuffer(
  function(err, data) {
    res.writeHead(200, {'Content-Type': doc.mimetype});
    res.end(blob, 'binary');
  }
);

The image shown now is resized to 1000 x 750, which is wrong (calculated based on the dimensions before autorotating).
If I restart node and run step 3 (generating thumbnail) again, the image shown is 1000 x 1333, which is correct.
I guess maybe this is due to a caching mechanism in Sharp / Libvips which keeps the original dimensions for a specific path cached.
See attached the original file with exif + generated thumbnails (both incorrect and correct version).
original file (with exif)

incorrect thumbnail

correct thumbnail

Any ideas?

"I guess maybe this is due to a caching mechanism in Sharp / Libvips which keeps the original dimensions for a specific path cached."

Spot on. sharp.cache can be used to modify/disable the libvips file cache.

Thanks for your quick reply! I managed to fix the issue by disabling and re-enabling the cache after writing the file - since I want the cache to be used.
Fix:
sharp(obj.path).rotate().toBuffer().then(
  function (buffer) {
    // Remember old caching settings
    var oldCache = sharp.cache();

    return new Promise(function (resolve, reject) {
      // Write buffer
      fs.writeFile(obj.path, buffer, function (err) {
        if (err) {
          reject(err);
        } else {
          sharp(obj.path).metadata().then(
            function (meta) {
              // Update the metadata (with and height have switched)
              obj.meta = meta;

              // Set the sharp cache to false and back to the old cache
              sharp.cache(false);
              sharp.cache(oldCache);

              // Resolve with the object
              resolve(obj);
            }
          ).catch(
            function (err) {
              reject(err);
            }
          );
        }
      });
    });
  }
);

Is this a good approach?
And secondly, any chance I can reduce this code to something like:
sharp(obj.path).rotate().toFile(obj.path);
.. without throwing this error:
Cannot use same file for input and output
(I was thinking using clone / a pipeline, but I'm not familiar enough with that concept)

When using the file system, libvips concurrently reads from the input file and writes to the output file, hence this limitation.
sharp.cache(false) empties the cache so I'd probably just disable it altogether if you really need to write to the same path.

Great, thanks thanks for your help!


Fix/namespace.not.updating

Fixes issue where namespaces where not updating after login.
Also adds github actions for pushing to docker hub on develop branch.
Updated Dockerfile so it builds the content as well.

@Vafilor see a few build checks that didn't pass

@rushtehrani One failed this morning because I forgot to commit my latest changes, the one right after that worked.
Any others stick out at you? Ones from yesterday were testing to get it setup.


Add block or width prop to Button component

Feature request
It would be really nice if there was a easy way to make any Button component span the entire parent. Either by adding a block prop like on the TextInput component or a width prop like on many other components.

Hey @albingroen! The Button component does have access to the width prop, though it looks like we forgot to update the docs when we added it. Going to close this in favor of a PR that updates the docs.
This should work:
<Button width="100%">Button</Button>

@emplums Hmm okay I see, although might there be some ts type missing there? Because ts won't let me enter a width prop on any button component 🤔


Pages using toc: true fail to compile

The recent i18n changes seem to have introduced a regression for pages with a table of contents.
In the included example site, I edited content/post/chapter-1.md to add toc: true to the front matter.  When I run hugo server, this generates the following error:
$ hugo server
Total in 33 ms
Error: Error building site: failed to render pages: render of "page" failed: execute of template failed: template: _default/single.html:46:10: executing "main" at <partial "menu-contextual.html" .>: error calling partial: "/home/james/www/themes/gohugo-theme-ananke/layouts/partials/menu-contextual.html:8:46": execute of template failed: template: partials/menu-contextual.html:8:46: executing "partials/menu-contextual.html" at <humanize>: wrong number of args for humanize: want 1 got 0

I tried with both Hugo v0.54.0 and v0.55.0-DEV-34C49D7, and see the same error.
It's not clear that this is a valid way to use the {{i18n}} function.  Maybe changing menu-contextual.html to pass . as the context, and move the humanize call into the translation is the right option?

Thank you, @jhenstridge I'll check this out.

I've fixed this in #168


Add<EMAIL_ADDRESS>

Hello @bazelbuild/bcr-maintainers, modules without existing maintainers (liburing) have been updated in this PR. Please review the changes.


[Feature Request] el-upload draggable image order if auto upload false

Existing Component
Yes
Component Name
el-upload
Description
It could be really usefull if every image when auto upload is false could be draggable so the user can change the order/positions of the image.

check imgpond

check imgpond


Wiki removal

This PR replaces all references to the wiki with links to readthedocs and/or files internal to the main repo.

Codecov Report

Merging #340 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #340      +/-   ##
==========================================
- Coverage   73.78%   73.76%   -0.02%
==========================================
  Files          59       59
  Lines        5340     5341       +1
==========================================
  Hits         3940     3940
- Misses       1400     1401       +1

Impacted Files
Coverage Δ

opentimelineio/adapters/cmx_3600.py
91.56% <ø> (-0.2%)
:arrow_down:

opentimelineio/adapters/adapter.py
96.61% <ø> (ø)
:arrow_up:

opentimelineio/plugins/manifest.py
90.47% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9b6aace...352f844. Read the comment docs.


Follow-up(add extension API): Remove ExtensionInterface and related functions/implementations

Current plan is to remove ClusterExtension, so no need to introduce an abstraction that will very shortly obsolete when we do remove ClusterExtension. If plans change and ClusterExtension sticks around, we can re-assess the need for an abstraction.

Once #642 merges, the types/functions mentioned in this issue become dead code. I've got a branch ready to rebase after that merges.


Design Equipment Model

We need to design a way to store equipment in database.

Additional tasks for Equipment model

[ ] Add verification for properties (check if property is allowed, does it have a valid type), on create and on update
[ ] Handle case where one of the category properties is changed (name, type)
[ ] Handle case where one of the category properties is removed
[ ] Test different case scenarios of saving equipment/equipment category properties


Email validation: input without domain suffix allowed

Hi, in my testing, for email fields, something like user@domain is considered valid, without the .com, etc. suffix
        <validate auto-label class="form-group required-field">
          Email
          <input class="form-control" v-model="registration.email" name="email" type="email" required<EMAIL_ADDRESS>/>

          <field-messages name="email" show="$dirty && $touched">

Email is a required field

Email is not valid

          </field-messages>
        </validate>

It's a bit of a tricky issue being discussed on every email-validator implementation I have seen so far.
The thing is that technically it is possible to have MX records on Top Level Domains, so e. g. mail@example could be valid mail address.
I think it is nowhere used for public emails, but e. g. in intranets it could be in place. Without the technical requirement of the Second Level Domain, it is difficult to enforce the validation on every library.
You can easily modify the existing validator Regex for a custom validator and register it when initializing vue-form.
For more about the topic see a similar discussion on Serverfault and feel free to close the issue if you think this resolved it.

There you go (better test it thoroughly, but should work)

I appreciate the offer to help. I'm assuming this code goes into your validators.js, it's not doing anything for me, but maybe I don't understand enough about how your plugin works.

See the update at the gist and the Custom Validators Section in the README.md.
For further questions please comment directly on the gist.


How can I get access to Vue.filter from model?

Hello.
Im not understand, how can I get access from model method to vue filters.
somethink like this:
someMethod()
{
   this.$options.filters.DoSomething(this.title)
}

Hello,
Vuex ORM Models are not instances of Vue Components so filters are not accessible through the $options object.
You can probably do something like this StackOverflow answer: https://stackoverflow.com/a/53067353

@mrFANRA As @tvillaren said, Vuex ORM Model instance is not Vue Component instance so you don't have access to Vuex Filters. However, since Due Filters are just a function, you could share them like this perhaps?
// Filter function `capitalize.js`.
export default function capitalize (value) {
  return value.charAt(0).toUpperCase() + value.slice(1)
}

// Vue Registration.
import capitalize from './capitalize'

Vue.filter('capitalize', capitalize)

// Vuex ORM Model.
import { Model } from '@vuex-orm/core'
import capitalize from './capitalize'

export default class User extends Model {
  // ...

  capitalizedName () {
    return capitalize(this.name)
  }
}

@kiaking @tvillaren Thank, Im using this way, but hoped ORM has Vue instance.
PS Thanks for awesome Vuex-ORM!

Thank you @mrFANRA! It could convenient to have Vuex Component instance access in Model, but technically it's really hard to do. I suppose you might already know but you could just pass this too ✋
export default class User extends Model {
  // ...

  capitalizedName (vm) {
    return vm.$options.filters.capitalize(this.title)
  }
}

export default {
  methods: {
    capitalize () {
      return User.capitalizedName(this)
    }
  }
}

Anyway, thank you so much for your report! Feel free to open another issue if you have anything! 👍


[2.x] Rename and deprecate public methods that contains 'master' in the name in 'server' directory (#3647)

Description
Backport PR https://github.com/opensearch-project/OpenSearch/pull/3647 / commit https://github.com/opensearch-project/OpenSearch/commit/1510b942bc05a89928e576300119f62871e5a1fd into 2.x branch.
To support inclusive language, the master terminology is going to be replaced by cluster manager in the code base.
This PR deprecate public and protected methods that contains master terminology in the name in server directory, except those covered by issue https://github.com/opensearch-project/OpenSearch/issues/3542 and https://github.com/opensearch-project/OpenSearch/issues/3543.
List of public methods that contain master in name that will be deprecated in this PR:
In directory - OpenSearch.server.main  (totally 27 class definitions)
public boolean hasDiscoveredMaster() {
public boolean localNodeMaster() {
public void updateMappingOnMaster(Index index, Mapping mappingUpdate, ActionListener<Void> listener) {
public boolean isBecomeMasterTask() {
public Optional<DiscoveryNode> getMasterNode() {
public PutRequest masterTimeout(TimeValue masterTimeout) {
public RemoveRequest masterTimeout(TimeValue masterTimeout) {
public static boolean isMasterNode(Settings settings) {
public boolean isMasterNode() {
public boolean isLocalNodeElectedMaster() {
public ImmutableOpenMap<String, DiscoveryNode> getMasterNodes() {
public ImmutableOpenMap<String, DiscoveryNode> getMasterAndDataNodes() {
public Stream<DiscoveryNode> mastersFirstStream() {
public String getMasterNodeId() {
public DiscoveryNode getMasterNode() {
public boolean masterNodeChanged() {
public DiscoveryNode previousMasterNode() {
public DiscoveryNode newMasterNode() {
public Builder masterNodeId(String clusterManagerNodeId) {
public boolean isLocalNodeElectedMaster() {
protected void assertClusterOrMasterStateThread() {
public void addLocalNodeMasterListener(LocalNodeMasterListener listener) {
public MasterService getMasterService() { (not changed in this PR)
public static boolean assertClusterOrMasterStateThread() {
void connectToRemoteMasterNode(TransportAddress transportAddress, ActionListener<DiscoveryNode> listener); (in interface, and not changed in this PR)
public synchronized void updateFromMaster(
public ClusterState joinNodesAndBecomeMaster(ClusterState clusterState, List<DiscoveryNode> nodes) {

The below test classes will not be renamed, because they are used to test the deprecated master node behavior.
public void testDoesNothingByDefaultIfMasterNodesConfigured() {
public void testDoesNotBootstrapsOnNonMasterNode() {
public void testDoesNotBootstrapsIfLocalNodeNotInInitialMasterNodes() {
public void testFailBootstrapWithBothSingleNodeDiscoveryAndInitialMasterNodes() {
public void testFailBootstrapNonMasterEligibleNodeWithSingleNodeDiscovery() {
public void testIsMasterNode() {

Other changes:

Changed 2 references of JoinTaskExecutor.newBecomeMasterTask() to use JoinTaskExecutor.newBecomeClusterManagerTask()

Issues Resolved
A part of issue https://github.com/opensearch-project/OpenSearch/issues/3544
Check List

[ ] New functionality includes testing.

[x] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #3964 (eede627) into 2.x (42ee012) will decrease coverage by 0.12%.
The diff coverage is 66.32%.

@@             Coverage Diff              @@
##                2.x    #3964      +/-   ##
============================================
- Coverage     70.61%   70.48%   -0.13%
+ Complexity    56407    56324      -83
============================================
  Files          4526     4526
  Lines        271706   271757      +51
  Branches      39974    39979       +5
============================================
- Hits         191860   191547     -313
- Misses        63729    64072     +343
- Partials      16117    16138      +21

Impacted Files
Coverage Δ

...n/cluster/health/TransportClusterHealthAction.java
47.75% <ø> (ø)

...settings/TransportClusterUpdateSettingsAction.java
46.55% <0.00%> (ø)

...min/cluster/state/TransportClusterStateAction.java
53.94% <0.00%> (ø)

...min/cluster/stats/TransportClusterStatsAction.java
70.83% <0.00%> (ø)

...g/opensearch/cluster/ClusterStateTaskExecutor.java
88.57% <0.00%> (-2.61%)
:arrow_down:

...g/opensearch/cluster/ClusterStateTaskListener.java
60.00% <0.00%> (-40.00%)
:arrow_down:

...org/opensearch/cluster/ClusterStateUpdateTask.java
100.00% <ø> (ø)

...org/opensearch/cluster/LocalClusterUpdateTask.java
92.85% <ø> (ø)

...rch/cluster/action/index/MappingUpdatedAction.java
70.49% <0.00%> (-2.39%)
:arrow_down:

...rdination/NodeRemovalClusterStateTaskExecutor.java
96.77% <ø> (ø)

... and 523 more

@nknize  Thank you so much for your review! 👍


ACCA shadow smear misaligned

The shadow-smear and original ACCA cloud mask are not aligned:

2723f3a fixes it.

In relation to this issue, when masks are applied to an image through gips, the masks are added to the metadata like this:
....
Metadata:
AREA_OR_POINT=Area
MASKS=2007242_LE7_acca 2007242_LE7_fmask
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
....
Maybe we should add the versioning of the acca mask to the metadata as we process new ones.

is this mask applied via gips_mask?

yeah this one was gips_mask on ref image using acca and fmask

OK.

The original issue is resolved.  @mcorbiere's comment is a good enhancement request that should be made an issue on its own.


Plugins issue

Expected Behavior
Some plugins should work
Actual Behavior
List of plugins:
https://insomnia.rest/plugins/insomnia-plugin-quicky-fake-data-generation
https://insomnia.rest/plugins/insomnia-plugin-user-agents
https://insomnia.rest/plugins/insomnia-plugin-user-picker
https://insomnia.rest/plugins/insomnia-plugin-prettyprint-request-response
https://insomnia.rest/plugins/insomnia-plugin-query-parameter-tag
https://insomnia.rest/plugins/insomnia-plugin-request-navigator
Errors Example:

Reproduction Steps
No response
Is there an existing issue for this?

[X] I have searched the issue tracker for this problem.

Additional Information
No response
Insomnia Version
8.6.0
What operating system are you using?
Windows
Operating System Version
Windows 10 Home 22H2
Installation method
from official source
Last Known Working Insomnia version
No response

Also having this issue


TypeScript definition lacks correct signature for 'SlackController'

When compiling a SlackBot with TypeScript, tsc gives me
node_modules/botkit/lib/Botkit.d.ts(282,5): error TS7010: 'setupWebserver', which lacks return-type annotation, implicitly has an 'any' return type.
A workaround is to allow implicit any in tsconfig.json, so that Botkit.d.ts passes the compile.

👍

This should be fixed in 0.6.4

This error go back in the version ^0.6.16
node_modules/botkit/lib/Botkit.d.ts(499,5): error TS7010: 'getUserById', which lacks return-type annotation, implicitly has an 'any' return type. node_modules/botkit/lib/Botkit.d.ts(500,5): error TS7010: 'getUserByUpn', which lacks return-type annotation, implicitly has an 'any' return type. node_modules/botkit/lib/Botkit.d.ts(501,5): error TS7010: 'getConversationMembers', which lacks return-type annotation, implicitly has an 'any' return type. node_modules/botkit/lib/Botkit.d.ts(502,5): error TS7010: 'getTeamRoster', which lacks return-type annotation, implicitly has an 'any' return type. node_modules/botkit/lib/Botkit.d.ts(503,5): error TS7010: 'updateMessage', which lacks return-type annotation, implicitly has an 'any' return type. node_modules/botkit/lib/Botkit.d.ts(504,5): error TS7010: 'getChannels', which lacks return-type annotation, implicitly has an 'any' return type.

@fredjsf care to submit a pr?


Merging two resumes is failing

It's possible this is user error but I wanted to post here and see. I have taken the base "Richard Hendriks" JSON from jsonresume.org and created an additional resume with the following content:
{
  "skills": [
    {
      "name": "Cat Herder",
      "level": "Master",
      "keywords": [
        "tabby",
        "feline",
        "tuna"
      ]
    }
  ]
}

When I run hackmyresume BUILD base.json test.json TO out.pdf it errors out with:
Reading resume: base.json
Reading resume: test.json
ERROR: Cannot read property 'name' of undefined
TypeError: Cannot read property 'name' of undefined
    at Object.module.exports.toFRESH     (/usr/local/lib/node_modules/hackmyresume/src/core/convert.js:29:25)
    at Object.module.exports.loadOne (/usr/local/lib/node_modules/hackmyresume/src/core/resume-    factory.js:69:64)
    at /usr/local/lib/node_modules/hackmyresume/src/core/resume-factory.js:38:21
    at Array.map (native)
    at Object.module.exports.load (/usr/local/lib/node_modules/hackmyresume/src/core/resume-    factory.js:37:22)
    at build (/usr/local/lib/node_modules/hackmyresume/src/verbs/generate.js:72:32)
    at Command.execVerb (/usr/local/lib/node_modules/hackmyresume/src/index.js:168:28)
    at Command.<anonymous> (/usr/local/lib/node_modules/hackmyresume/src/index.js:105:16)
    at Command.listener     (/usr/local/lib/node_modules/hackmyresume/node_modules/commander/index.js:301:8)
    at Command.emit (events.js:110:17)

Doing just a hackmyresume BUILD base.json TO out.pdf works ok, it's only when I add in the test.json file to be merged that it fails.
hackmyresume VALIDATE base.json test.json TO out.pdf comes back with:
Reading resume: base.json
Reading resume: test.json
Reading resume: TO
Reading resume: out.pdf
Validating base.json against JSON RESUME schema: VALID!
Validating test.json against JSON RESUME schema: VALID!
Validating TO against AUTO schema: BROKEN
ERROR: Error: ENOENT, no such file or directory 'TO'
Validating out.pdf against AUTO schema: BROKEN
--> OUT.PDF contains invalid JSON on line 1 column 1. Unable to validate.
    INTERNAL: SyntaxError: Unexpected token %

I am on version 1.4.0 of hackmyresume.

There are a minimum number of fields that need to be present in both the json files, your test.json file does not have the name nor info fields which IIRC are required.
Make sure both files validate correctly, also, is that meant to be jsonresume or fresca?
Validating a fresca json with just this content gives me:
{
  "meta": {
    "format"<EMAIL_ADDRESS>    "version": "0.1.0"
  }
}

> hackmyresume VALIDATE cv2.json
Reading resume: cv2.json
Validating cv2.json against FRESH schema: INVALID
--> RESUME.NAME is required
--> RESUME.INFO is required

Which indicates that at a bare minimum both files need the following:
{
  "name": "Jane Q. Fullstacker",
  "meta": {
    "format"<EMAIL_ADDRESS>    "version": "0.1.0"
  },
  "info": {
  }
}

Thanks @RichyHBM, that was it. I had to add the "basics" section into my test.json file and then it worked.
I had been using the test resume from https://github.com/hacksalot/HackMyResume/blob/master/test/resumes/jrs-0.0.0/richard-hendriks.json which I believe is the jsonresume format.
I'll go ahead and close this out, thanks again for the help!


feat(supplier): pause/resume main process

WIP currently, only contains the functions in the main process
They are not called. The process executor must have a way to call them.
covers #33

@assynour I have just created this PR with some code I have started working on.
I don't plan to work on this topic soon, feel free to post a comment if you want to work on it.
I will post one myself if I plan to work on this topic again.

@assynour I have just created this PR with some code I have started working on. I don't plan to work on this topic soon, feel free to post a comment if you want to work on it. I will post one myself if I plan to work on this topic again.

I will start working on it


Update a size of the lib on the https://angular-ui.github.io/bootstrap/

Hi guys,
Here is a small PR to update the size that is shown on the main page.
I've used terminal to get sizes.

~/Desktop du -hs ui-bootstrap-tpls-0.13.0.min.js*
76K	ui-bootstrap-tpls-0.13.0.min.js
20K	ui-bootstrap-tpls-0.13.0.min.js.gz

This is filed against the wrong branch. gh-pages is autogenerated, please file against master.


False positive: No public access block (AWS S3)

Hello,
I am currently experiencing false positives when scanning valid Terraform JSON with tfsec.
My JSON contains following resources:
"aws_s3_bucket": {
  "live-s3": {
    "bucket": "test-bucket"
  }
},
"aws_s3_bucket_public_access_block": {
  "s3-bucket-access-block": {
    "block_public_acls": true,
    "block_public_policy": true,
    "bucket": "${aws_s3_bucket.live-s3.id}",
    "ignore_public_acls": true,
    "restrict_public_buckets": true
  }
}

Nonthenless I get multiple warnings saying that I do not configure a public access block for my bucket which is clearly not correct.
I already searched for related issues and found this one.
It is marked as closed but there are still cases where this false positive will emerge. I tried to pinpoint the problem and it seems that the referencesFromExpression() function in file parsers/terraform/attribute.go misses a case where the expression can be of type *hcl/v2/json.expression. I tried to fix this behaviour, but the expression type is not exported so the fix has to use reflection.
I propose the following changes for the function:
func (a *Attribute) referencesFromExpression(expression hcl.Expression) []*Reference {
	var refs []*Reference
	noTypeMatch := false
	switch t := expression.(type) {
	case *hclsyntax.ConditionalExpr:
		// no changes
	case *hclsyntax.ScopeTraversalExpr:
		// no changes
	case *hclsyntax.TemplateWrapExpr:
		// no changes
	case *hclsyntax.TemplateExpr:
		// no changes
	case *hclsyntax.TupleConsExpr:
		// no changes
	case *hclsyntax.RelativeTraversalExpr:
		// no changes
	default:
		noTypeMatch = true
	}

	if !noTypeMatch {
		return refs
	}

	// Can not go inside the switch case because the hcl/v2/json.expression type is not exported
	if reflect.TypeOf(expression).String() == "*json.expression" {
		if ref, err := createDotReferenceFromTraversal(a.module, expression.Variables()...); err == nil {
			refs = append(refs, ref)
		}
	}

	return refs
}

When I run my test with the new implementation the false positive is not shown anymore. Are those changes viable for a PR? If not, I can do some fixes first and then open a PR.

Hi @CptKirk - thanks, this looks like a nice solution. I think you could move the code inside the default: case of the type switch (and only set noTypeMatch if your if fails.).

Btw, the code is now in pkg/terraform/attribute.go

@liamg Thanks for your input. I moved the code inside the default: case, but setting the noTypeMatch var to true if the if statement fails yields a compile error, because the variable is not used. Therefore I will exclude the noTypeMatch var from my PR.


Reference for new run_events.txt spec

Write up of #60 in a format that can be merged. I've gone with the event_sequence idea instead of run_event_id. Other than that there are minor text changes and some reformatting, but no semantic changes.
The changes to the spec are all in the one file index.md. Here's a link to the diff and the rendered version
I've also rewritten all of the examples (which is why there are so many deleted files). Here's a rendered version of examples.md
Status as of 2024-07-01: #61 was merged and I've updated this PR so it only contains new changes.

Here's a link to just the changes that weren't already voted on in #61.
The changes to the spec are all in the one file index.md. Everything else is changes to examples (link to rendered preview of new examples).

VOTING PERIOD OPEN
Voting is now open on this proposal through 11:59:59 UTC on 16 July 2024. This proposal is the second of two for the TODS 2.0.0 release. If adopted, this proposal will be released as TODS 2.0.0.
WHO IS ELIGIBLE TO VOTE
Any individual may vote as an ODS Contributor; in voting, Contributors are acknowledging and agreeing to the ODS Contributor Agreement and ODS Code of Conduct.
TODS Board Members are eligible to vote, provided that they are not also Issue Working Group members.
Issue Working Group members (@safrazier17, @jeffkessler-keolis, @jfabi, and @skyqrose) are not eligible to vote on this proposal.
HOW TO VOTE

A vote of support for this PR, comment "+1 [Individual or Organization Name]"
To support the proposal with a minor correction, add one comment to the PR including both the correction and "+1 [Individual or Organization Name]"
To vote for a substantial revision to the proposal, comment "-1 [Individual or Organization Name]" along with a brief description of what you believe needs to be substantially revised before the proposal can be adopted. NOTE: TODS governance requires that voters requesting substantial revision commit to working with the Issue Working Group to develop their recommended revision.

OUTCOMES

At the end of the voting period, if the proposal has received at least THREE (3) +1 votes from stakeholders outside of the Issue Working Group and votes of "Support with Minor Correction" or "Substantial Revision," the proposal is immediately adopted.
If the proposal receives one or more votes of "Support with Minor Correction," the Issue Working Group may decide whether to incorporate the recommended changes or to appeal to the Board for consideration of the necessity of the recommended changes.

If the issue working group or the Board determine that the minor changes should be incorporated into the proposal, the proposal shall be updated and the TODS community shall be notified of the updates. After a period of FOUR (4) business days, the proposal shall be adopted immediately unless valid objections to the minor changes are received. No new voting period is automatically initiated.

If the proposal receives one or more votes of substantial changes, the author(s) of the recommended changes must commit to working with the issue working group to develop an alternative proposal that meets the need raised by the reviewer. The issue working group may appeal to the Board if they believe a recommended substantial change is without merit.

If a proposal is substantially changed, then a new voting period must be opened before the amended proposal can be adopted.

If the proposal does not meet the minimum threshold for votes outside of the issue working group, the working group may appeal to the Board for a decision. The Board may vote to adopt the proposal or to require a new voting period.

Liking this proposal overall but I have one clarification question. For, start_time, it's stated:

If trip_id is set (and mid_trip_start is not 1), this should be the time of the first stop of the trip (after applying any trip supplement).

What about cases where the arrival_time and departure_time of the first stop_time on the trip differ? The analogous question applies for end_time.
One thought is that for start_time we could prefer arrival_time in the case of a discrepancy and then for end_time prefer departure_time, though I haven't thought about it long enough to know whether there are any obvious issues with that approach.

What about cases where the arrival_time and departure_time of the first stop_time on the trip differ?

Good catch, I hadn't considered that there might be two separate times.
The intent is to represent when the employee is working on that trip. If the first stop has different arrival_time and departure_time, then that probably means the vehicle is sitting berthed with the doors open. The operator isn't necessarily on board then, they could hop on just before the departure_time. So run_events.start_time should probably correspond with the stop_times.departure_time.
Similarly, for the last stop, the vehicle could arrive, the operator could open the doors, and hop off leaving the doors open for passengers, so they'd only be working on that trip until stop_times.arrival_time.
I'll update the text to make that a little clearer and give a recommendation, but producers could fill the field differently if they consider an employee to be working starting at arrival_time or ending at departure_time.

Does start_mid_trip or end_mid_trip matter if we have to indicate a start_time and end_time anyway? I guess, for me, it's not clear why we need it. Does start_time and end_time have to correspond with stop_times.start_time and stop_times.end_time?

+1 from WMATA with minor corrections:

Per @BTollison's comment, curious about start_mid_trip/`end_mid_trip. Willing to accept with or without the field so didn't want to vote against since the rest looks good.
The "Run As Directed" example clarified things, but for block_id, the definition for run_events in index.md states it references trips.block_id. I think changing that to "references trips.block_id if available" would probably cover Strategic Buses/Extras where there is no trips.block_id available?

I also think the first sentence in the definition might be a little unclear, stating:

If block_id exists, trip_id exists, and that trip's entry in trips.txt has a block_id, then the two block_ids must match.

I think switching that around to:

If trip_id is set, and the associated trip in trips.txt has a block_id, then the two Block IDs must match.

might be clearer? Open to suggestions

Reading the proposal over again a bit, I think the way it's setup currently doesn't allow for unattended reliefs?
My recommendation here is that start_time and end_time be the start and end time regardless of stops_times.txt. This way we don't need start_mid_trip or end_mid_trip. We already have trip_id, so it seems okay to do it this way?
If we can agree on this -- or some version of this I'm +1.

Bill:
start_mid_trip/end_mid_trip are useful to have because a mid-trip relief is a complex case that will be a lot easier to detect and handle if it's called out explicitly instead of needing to detect it by comparing run_events.txt to trips.txt and stop_times.txt. It makes producing a little harder in order to make consuming a lot easier and less error prone. If an agency never does mid-trip reliefs, then they can leave the whole column out. If an agency does do mid-trip reliefs, then the complexity has to go somewhere, and I think here is a good place for it.
run_events.start_time should correspond to stop_times.arrival_time or stop_times.departure_time, because presumably an employee will start working on the trip when the trip starts. (Unless it's a mid-trip relief, in which case it corresponds to the stop_time.arrival/departure_time of the stop where the employee starts working that trip.) It's SHOULD, not MUST, because maybe some agency has a reason to do something weird with it, but having the run event times correspond to the trip times is the intent. (If we wanted to skip the start/end_mid_trip fields, then producers would need to MUST exactly match stop_times.txt in order for consumers to detect mid-trip reliefs.)
What do you mean by "unattended reliefs"?

My recommendation here is that start_time and end_time be the start and end time regardless of stops_times.txt.

Can you clarify what you mean? start_time and end_time should be start and end time of what?
Erik:
👍 to the minor text changes, I'll add those (or something like them) tomorrow. (One minor change I'll make: It should be okay for trips.txt to have a block_id and run_events.txt to leave it blank. I just want to make sure they're not conflicting.)
Scott:
Is it okay to delay the end of voting for a bit so we can finish the discussions about start/end time?

Sorry,  I meant that start and end times I think should be the event start and end time.
An unattended relief is when a driver does not need to cover the vehicle when a relief is being made. So, driver A brings the vehicle, but no driver is waiting to take over. The vehicle may sit for minutes or hours, and driver B could show up any time before the next trip on the block. I think though this is actually okay in the way it's written now in the spec.. because a driver would not typically "cover" the vehicle until they must drive it somewhere or do something related to it (sign-on). What do you think?
I do wonder though, what about reliefs that are covered but happen in the middle of a layover? I think in this case we do have an issue because Driver A must cover the vehicle +x minutes after a stop_times.departure/arrival_time and Driver B can take over to cover the vehicle -x minutes before the next stop_times.departure/arrival_time?

Unattended reliefs should be fine to represent. Example, where the vehicle sits 3 hours unattended before another operator signs in and continues the block:
# stop_times.txt
trip_id,arrival_time,stop_id,stop_sequence
101,10:00:00,stop-1,10
101,10:05:00,stop-2,20
102,13:00:00,stop-2,10
102,13:05:00,stop-1,20

# run_events.txt
service_id,run_id,event_sequence,piece_id,block_id,job_type,event_type,trip_id,start_location,start_time,start_mid_trip,end_location,end_time,end_mid_trip
daily,run-1,10,,       ,Operator,sign-in ,   ,stop-1,09:55:00, ,stop-1,10:00:00,
daily,run-1,20,,block-1,Operator,Operator,101,stop-1,10:00:00,0,stop-2,10:05:00,0
daily,run-2,10,,       ,Operator,sign-in ,   ,stop-2,12:55:00, ,stop-2,13:00:00,
daily,run-2,20,,block-1,Operator,Operator,102,stop-2,13:00:00,0,stop-1,13:05:00,0

For the case where an Operator is responsible for a vehicle 1 minute before/after every trip, you're right that the descriptions are unclear about which time to use.
If the descriptions were changed to this:

start_location (unchanged):
Identifies where the employee starts working this event.
If trip_id is set (and mid_trip_start is not 1), this should be the stop_id of the first stop of the trip in stop_times.txt (after applying any trip supplement). If start_mid_trip is 1, this should be the location where the employee starts, matching a stop_id in the middle of the supplemented trip.
start_time (changed):
Identifies the time when the employee starts working this event.
If trip_id is set (and mid_trip_start is not 1), this corresponds to the time of the first stop of the trip in stop_times.txt (after applying any trip supplement). If start_mid_trip is 1, this time corresponds to a stop time in the middle of the supplemented trip, when the employee starts working on the trip. Note that this time may not exactly match stop_times.txt arrival_time or departure_time if the employee is considered to be working for a couple minutes before the trip departs. This field is about when the employee is working, and consumers who care about the the trip times should check stop_times.txt instead.

would that help? I explicitly allowed the time to be different from the trip time, and clarified that this file is about employee work times, and if a consumer wants trip times they should come from stop_times.txt. I left the location as "should match stop_times.txt" because anything complex enough to require movement should probably be a different event, and it'll make matching to stop_times.txt easier.

@skyqrose I can extend if we need to. I have asked @lemald to clarify whether or not he intended to vote yes with minor correction with his comment. If so, then we don't need to extend as we will have met the minimum vote threshold and can figure out the minor correction requested by Bradley. At that point, there will be a ~three day window for the voters to withdraw their votes.

Hey all,
I have 2 comments:

Not a fan of the mid_trip flags - what is the use case/the upside? If that was described somewhere, just point me to it, but I didn't see it.
Not on board with "Events may overlap in time" - whose data model supports that? E.g., does anyone's dispatch software allow for assigning an operator to multiple runs/duties at the same time?

@skyqrose I can extend if we need to. I have asked @lemald to clarify whether or not he intended to vote yes with minor correction with his comment. If so, then we don't need to extend as we will have met the minimum vote threshold and can figure out the minor correction requested by Bradley. At that point, there will be a ~three day window for the voters to withdraw their votes.

Hi - yes, sorry, that was my intent.
+1 from me, Eddie Maldonado, at MBTA, with the minor corrections already under discussion.

Scott, I saw the explanation that mid_trip should be easier to calculate during the export than when it is needed on the fly, but I don't see how or when it would be needed on the fly. I can see it as a consistency check as in "yes, the relief is really meant to be in the middle of the trip, this is not an error", but that's a feature that a software should calculate when it needs it, and not a data item. I don't like redundant data, especially when I don't see a common use case.

Matthias:

The mid_trip flags are needed to represent mid-trip reliefs, where an operator gets off a vehicle and a new operator gets on in the middle of a trip, while passengers are on board.

MBTA does this all the time on bus and subway when a yard is in the middle of the line, so operators can have a shift change without taking a vehicle out of service. I believe it's common at other agencies, too, though not every agency does it.
The fields are needed because this is an important case to handle in our operational software, and without the fields it would be difficult/tedious for a consumer to detect this case just by comparing run_events.txt and stop_times.txt. In general, I think mid-trip reliefs are a complex case that's likely to cause problems for many consumers, so I think it's worth extra effort by the producers to make it more explicit and less error-prone for consumers.
This has come up a couple times, so I've added a note that "If an agency does not use any mid-trip relief, the whole column may be omitted."

The overlapping events is more hypothetical. Here's a couple of situations where it could be useful:

An agency wants to use events for labeling parts of the day. Like one event for "operating vehicles 16:00-22:00" and one for "operating vehicles at the overnight pay rate 22:00-25:00" and those events overlap with the run events for the trips being done at those times.
An employee has multiple responsibilities (maybe fare collection and door operation) that are represented as separate events for the same trip.

But the motivation is less that these are important features to support, and more that forcing events not to overlap would be a restriction that I don't see a reason to enforce. It's unlikely to make a significant difference to consumers, but it could make a difference to producers who want to use run_events to represent a bunch of different types of events.
I'm not too attached to overlapping events, and I think that the spec ended up a little more complicated than it should need to be to express the fact that there's not a restriction there. If you think restricting events to not overlap is important, or if you have an idea for how to redo the event_sequence field and description so that it's less complicated (maybe it should not even try to be a sequence, and should just be an id that's unique within the run?) then I'm open to suggestions.

Oh also, based on discussions above about how it's okay if the event times don't exactly line up with the trip times, and how to handle stop_times with different arrival_time and departure_times, that makes it even harder for a consumer to check if a given run_event covers the whole trip. The producer is better able to know how to handle these gotchas correctly for their data.

Sky,

I agree that mid-trip reliefs are not uncommon, but I still don't see what that flag would do. A relief is a relief, and a shift end is a shift end, so what would happen if a driver reliefs in the middle of the trip without such a flag being set? I'm just thinking about which field this could be imported into in INIT's data model, or in which view it could be displayed, or in which function it could be used to achieve a specific outcome, and I don't see any application for it.
The first example is not an overlapping event, it's just a duty split into 2 different tasks, which is no problem. As for the second example, there would be 2 distinct duties called fare collection and door operation, and a dispatching software would have to be able to assign a single operator to 2 duties at once. I don't know if any software can do this.

I think I would advocate that we adopt the restriction of no overlapping events, with the understanding that when/if a use case arises in the future, we could always take up the topic again and eliminate the restriction. That would be in line with how we have handled similar questions (e.g. Only creating four gtfs supplement files instead of speculatively providing for additional ones).

Unattended reliefs should be fine to represent. Example, where the vehicle sits 3 hours unattended before another operator signs in and continues the block:
# stop_times.txt
trip_id,arrival_time,stop_id,stop_sequence
101,10:00:00,stop-1,10
101,10:05:00,stop-2,20
102,13:00:00,stop-2,10
102,13:05:00,stop-1,20

# run_events.txt
service_id,run_id,event_sequence,piece_id,block_id,job_type,event_type,trip_id,start_location,start_time,start_mid_trip,end_location,end_time,end_mid_trip
daily,run-1,10,,       ,Operator,sign-in ,   ,stop-1,09:55:00, ,stop-1,10:00:00,
daily,run-1,20,,block-1,Operator,Operator,101,stop-1,10:00:00,0,stop-2,10:05:00,0
daily,run-2,10,,       ,Operator,sign-in ,   ,stop-2,12:55:00, ,stop-2,13:00:00,
daily,run-2,20,,block-1,Operator,Operator,102,stop-2,13:00:00,0,stop-1,13:05:00,0

For the case where an Operator is responsible for a vehicle 1 minute before/after every trip, you're right that the descriptions are unclear about which time to use.
If the descriptions were changed to this:

start_location (unchanged):
Identifies where the employee starts working this event.
If trip_id is set (and mid_trip_start is not 1), this should be the stop_id of the first stop of the trip in stop_times.txt (after applying any trip supplement). If start_mid_trip is 1, this should be the location where the employee starts, matching a stop_id in the middle of the supplemented trip.
start_time (changed):
Identifies the time when the employee starts working this event.
If trip_id is set (and mid_trip_start is not 1), this corresponds to the time of the first stop of the trip in stop_times.txt (after applying any trip supplement). If start_mid_trip is 1, this time corresponds to a stop time in the middle of the supplemented trip, when the employee starts working on the trip. Note that this time may not exactly match stop_times.txt arrival_time or departure_time if the employee is considered to be working for a couple minutes before the trip departs. This field is about when the employee is working, and consumers who care about the the trip times should check stop_times.txt instead.

would that help? I explicitly allowed the time to be different from the trip time, and clarified that this file is about employee work times, and if a consumer wants trip times they should come from stop_times.txt. I left the location as "should match stop_times.txt" because anything complex enough to require movement should probably be a different event, and it'll make matching to stop_times.txt easier.

Alright, I'm good with this.
I tend to agree with @Matthias-Gruetzner on the mid_triip field but it isn't a blocker for me.
+1 from Transdev Group.

From my side:

mid_trip Flags

I'm indifferent with the mid_trip flags being included or omitted.
I do think they provide value with respect to highlighting instances in which employees are re-crewing a trip en-route, but they could always be reverse-engineered from the underlying data as needed.
If people have qualms about this, perhaps this field is made optional and could be used at the producer's discretion?

Arrival/Departure Correspondence in Mid-Trip Reliefs

@BTollison raised a good point with respect to instances in which an arrival/departure time vary.
I think the vast majority of producers will have these values be identical, but in the instances in which they're not, I see the case in which it could match the arrival time, the departure time, or even neither (occurring somewhere in the middle).
I would strongly discourage the case where an employee's event on a trip precedes the arrival_time or succeeds the departure_time.

Doing so would limit the ability to distinguish between an employee arriving at a stop early to relieve another operator vs two employees working on the same trip at the same time.
Example: An employee alighting at a stop "on the trip," letting a train continue somewhere and returning to the original station, at which point the employee returns onboard the trip.
Granted, the above example is limited to a handful of edge-case networks, although there could be minor discrepancies in times between systems for which coupling the trip times and event times admittedly need not be mandatory.
I'd propose the language is thus modified to "this time SHOULD match the arrival_time, departure_time, or any time in-between."

Permission/Restriction of Overlapping Events

I think the idea here was to show instances in which a scheduling software has someone on a piece like "availability" or "protect," and then has them covering a trip on top of that.
Likewise, the practice could be used to show employees having a particular duty / activity over which their specific work is included.
Per my understanding, if any restriction were needed, it would simply be that an employee can not be on two trips at the same time, but that they could otherwise be undertaking two activities at the same time.
This is not a blocker for me moving forward, and I'm fine having this come in at a later point in the spec as applicable, but I wouldn't want people to build implementations such that this subsequently becomes a breaking change.

Mid trip reliefs:
To show a concrete application of this field, here's an example screenshot from one of MBTA's internal bus operations tools, showing how a run's second piece starts mid-trip, along with where and when and on what run that trip started:

Displaying this information to bus dispatchers and officials helps them run service better (compared to thinking that this was a normal relief during a layover). E.g. an official at Andrew Station, where the swing will take place, would see this information, and then be better prepared to make sure that the shift change happens quickly without delaying passengers on the bus.
That said, if there's this much push back against the field, and not everyone would find it useful, then I like Jeff's suggestion of making it optional. If a producer and consumer both find it valuable, then they can include it. If a producer doesn't want to include it (because it would be extra work to compare to the trip times), then they don't have to. And if a consumer wants it but the producer didn't include it, they can recalculate it.
I propose this format:

start_mid_trip Enum Optional
Indicates whether the event begins at the start of the trip or in the middle of the trip (after applying any trip supplement).
0 or blank - Run event is not associated with a trip, or no information about whether the run event starts mid-trip.
1 - Run event starts mid-trip.
2 - Run event starts at the first stop of the trip.

Arrival/Departure correspondence
I don't think we should strongly suggest that times line up to stop times. Ensuring that would require the producer to compare data to stop_times.txt, which (based on the discussion about calculating the mid-trip fields) we want to avoid forcing the producers to have to do. If we don't require this, then for some producers it might become possible to make run_events.txt by looking only at crew schedules and not at trip schedules.
You're right that it could be ambiguous which stop_sequence a run_event starts at if a trip visits the run_events.start_location multiple times and the run_events.start_time doesn't line up with a stop_times.arrival/departure_time, but I don't think that's worth worrying about in practice.
I think the description should suggest that this will correspond to stop times because it will help producers understand the intent of the field, but if we want to avoid producers comparing to trip times, then I don't think the spec should describe matching to trip times as a SHOULD or MUST.
Overlapping Events
Thanks for the example about available / protected time.

So far I stick with my concerns and cannot accept the mid_trip flags and the overlapping events. I guess that makes it a "Support with Minor Correction".

Mid trip reliefs:
To show a concrete application of this field, here's an example screenshot from one of MBTA's internal bus operations tools, showing how a run's second piece starts mid-trip, along with where and when and on what run that trip started:

Displaying this information to bus dispatchers and officials helps them run service better (compared to thinking that this was a normal relief during a layover). E.g. an official at Andrew Station, where the swing will take place, would see this information, and then be better prepared to make sure that the shift change happens quickly without delaying passengers on the bus.
That said, if there's this much push back against the field, and not everyone would find it useful, then I like Jeff's suggestion of making it optional. If a producer and consumer both find it valuable, then they can include it. If a producer doesn't want to include it (because it would be extra work to compare to the trip times), then they don't have to. And if a consumer wants it but the producer didn't include it, they can recalculate it.
I propose this format:

start_mid_trip Enum Optional
Indicates whether the event begins at the start of the trip or in the middle of the trip (after applying any trip supplement).
0 or blank - Run event is not associated with a trip, or no information about whether the run event starts mid-trip.
1 - Run event starts mid-trip.
2 - Run event starts at the first stop of the trip.

Arrival/Departure correspondence
I don't think we should strongly suggest that times line up to stop times. Ensuring that would require the producer to compare data to stop_times.txt, which (based on the discussion about calculating the mid-trip fields) we want to avoid forcing the producers to have to do. If we don't require this, then for some producers it might become possible to make run_events.txt by looking only at crew schedules and not at trip schedules.
You're right that it could be ambiguous which stop_sequence a run_event starts at if a trip visits the run_events.start_location multiple times and the run_events.start_time doesn't line up with a stop_times.arrival/departure_time, but I don't think that's worth worrying about in practice.
I think the description should suggest that this will correspond to stop times because it will help producers understand the intent of the field, but if we want to avoid producers comparing to trip times, then I don't think the spec should describe matching to trip times as a SHOULD or MUST.
Overlapping Events
Thanks for the example about available / protected time.
Restricting trips from overlapping seems like an okay compromise. It would allow the cases about available/protected time, and would remove the most unintuitive part of overlapping events. But it would still require the complexity of event_sequence, could hypothetically make a producer unable to represent their schedule, and could still cause a breaking change for consumers if we want to allow overlapping events on trips in the future. So I'd be willing to compromise on it, but I'd still prefer to not restrict any overlaps.
(Whoops, I closed and reopened the pull request. That was an accident.)

So far I stick with my concerns and cannot accept the mid_trip flags and the overlapping events. I guess that makes it a "Support with Minor Correction".

@Matthias-Gruetzner we would call this a vote for a substantial revision.

Does making the field optional resolve your concern about its inclusion?
If not, can we (issue working group plus Matthias) schedule a call to figure out how we can account for this use case (as I understand it, being able to directly tie a run's entire event composition to a trip or stop time within a trip) differently?

@Matthias-Gruetzner can you let me know by EOD Friday whether making the field optional works for you? else, I will set up a working group meeting including you for further discussion

Sky thinks it's useful and apparently intends to use it, so I won't block it. But yes, the entire 2 columns for mid trip should be optional.
If we do that, and remove allowing overlapping events: +1 from me.

For overlapping trips, would a zero minute trip count as an overlapping trip? My guess is yes.
A zero minute trip is when a trip has no duration (0 minutes), so starting at 12:00 and ending at 12:00, then is proceeded by a "real" trip whether it is in revenue or not and starts at 12:00 also. In Hastus, this is a standard outcome for when you use the remake block feature for pull and taxi reliefs. In many instances I have seen the use of a zero minute trip as a way to create logistical movements that would otherwise not be possible when using an optimizer.
The zero minute trip in Hastus serves the purpose of creating an anchor point for a pull or deadhead when there is otherwise nothing to anchor on.

Voting period outcome
The voting period ended on Tuesday, July 16 at 23:59:59 UTC. Votes recorded for this pull request were as follows:

@wmata-eajensen (WMATA): +1 with minor corrections
@lemald (MBTA): +1 with minor corrections
@BTollison (Transdev): +1 with minor corrections
@Matthias-Gruetzner (INIT): +1 with minor corrections (see note below)

The vote has met the minimum threshold for support. Because there were multiple votes of support with minor corrections, voters have until Tuesday, July 23 at 23:59:59 UTC to either retract or affirm their vote of support for this proposal. @skyqrose please confirm when we have a final Pull Request that reflects the requested changes including:

Optional start_mid_trip and end_mid_trip
Restricting overlapping trips

If we retain >= 3 votes of support at the end of the review period, the proposal will be adopted as TODS 2.0.0.
(note: There is a lack of guidance in the current governance docs as to what should be considered a minor requested change vs a substantial revision. As it stands, Matthias's initial vote was a -1 vote for substantial revision because the vote was contingent upon the removal of two fields (start_mid_trip and end_mid_trip) included in the pull request. A compromise proposal was reached in which the fields were retained but the constraints were altered such that the fields would be purely optional, rather than conditionally required. Matthias amended his vote to +1 on this basis. I will ask the Board for additional guidance and updates to the governance docs to help account for similar cases in the future, but am comfortable with recording this vote as having 4 votes of support with minor corrections.)

👍 I will edit the spec to make start_mid_trip and end_mid_trip optional.
🤔 Overlapping trips is less clear. I'd like a little more discussion on it.

I have several questions for everyone:

What are people's reasons for wanting overlapping events to be prohibited?
Would prohibiting overlapping trips but allowing other non-trip events to overlap be okay?
Are there other solutions (maybe trying to simplify the docs for event_sequence?) that would resolve the objections while still allowing overlapping trips?

My opinion is that overlapping non-trip events are useful, and although they could be removed, it'd be limiting for some use cases. Overlapping trips are not useful, but it seems simpler, more forward-compatible, and potentially hypothetically useful to allow them. I'm willing to prohibit overlapping trips but want to understand a little more about the objections first to make sure that a compromise actually addresses people's objections.

A "run" is the workload of a person on an operating day (~duty), similar to what a block is for a vehicle. A run can be split into different pieces, just like a block can consist of many trips. And just like there cannot be overlapping trips in a block, there cannot be overlapping pieces of a run. And it doesn't matter whether the pieces are trip-related or not. A driver cannot do 2 tasks called "yard cleaning" and "vehicle inspection" at the same time. If he has to do both, it has to be 1 task called "yard cleaning and vehicle inspection".
No blocking software can purposefully create overlapping trips in a block, and no runcutting and dispatching software accepts overlapping pieces. Or am I mistaken?

I've been talking with a couple people 1:1 about overlapping run events.

👍 I'll change the spec to prohibit overlapping trips.

I thought having overlapping trips would allow more flexibility and make the spec more useful, but despite looking, I haven't heard of any concrete situations where it'd be needed. Making the spec easy to understand and a little easier for consumers outweighs any hypothetical future situations. There is a bit of a risk that if a concrete situation for overlapping trips does pop up in the future, it'd be a difficult backwards-incompatible change for consumers, but that risk seems to be worth taking.
I'm planning to keep allowing overlapping events (which aren't trips) because having sections of the day (such as available/protected time) is much more likely to be useful and pop up in real situations.
I will also relax the rules for event_sequence to make the spec a little simpler and easier to follow.

I've made all edits (including making start/end_mid_trip optional, and prohibiting overlapping trips, but not prohibiting non-trip events). I've given everything one last readthrough and made a couple final minor wording tweaks. It's good to merge now!

Yes, we’ll leave as-is for now
On Thu, Aug 1, 2024 at 3:28 AM Jeff Kessler @.***>
wrote:

@.**** commented on this pull request.
In docs/spec/index.md
https://github.com/cal-itp/operational-data-standard/pull/66#discussion_r1699915280
:

@@ -20,8 +20,7 @@ There are two types of files used in the TODS standard:
| stops_supplement.txt | Supplement | Supplements and modifies GTFS stops.txt with internal stop locations, waypoints, and other non-public stop information.|
| stop_times_supplement.txt | Supplement | Supplements and modifies GTFS stop_times.txt with non-public times at which trips stop at locations, stop_times entries for non-public trips, and related information. |
| routes_supplement.txt | Supplement | Supplements and modifies GTFS routes.txt with internal route identifiers and other non-public route identification. |
-| runs_pieces.txt | TODS-Specific | Defines daily personnel schedules within a feed. |
-| run_events.txt | TODS-Specific | Defines other scheduled activities to be performed by a member of personnel during a run. |
+| run_events.txt | TODS-Specific | Lists all trips and other scheduled activities to be performed by a member of personnel during a run. |

The use of the Supplement standard to modify other GTFS files is not yet formally adopted into the specification and remains subject to change. Other files may be formally adopted in the future.
That works for me, although I'm not sure how that fits into the broader
scope of things given that (a) it wasn't officially proposed during the
vote itself; and (b) that was technically already approved as part of #61
https://github.com/cal-itp/operational-data-standard/pull/61's PR, not
this one. If we don't want to pursue for the sake of governance, perhaps we
add that tweak to 2.1's planned changes.
—
Reply to this email directly, view it on GitHub
https://github.com/cal-itp/operational-data-standard/pull/66#discussion_r1699915280,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALKK7YEVZHSDOBQJLT2XIHTZPIETLAVCNFSM6AAAAABFSJ362GVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDEMJSGM2TCOJTGU
.
You are receiving this because you were mentioned.Message ID:
@.***>