text:
ST_MGCN

Windows 10　无GPU,
python==3.6
tensorflow==1.13
Keras==2.2.4
h5py==2.9.0
UCTB==0.3.0
运行文件：UCTB/Experiments/ST_MGCN/bike_trial.py 报错：
想请问一下原因？一定要使用GPU吗？
Using TensorFlow backend.
2021-10-09 18:10:20.332752: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2
[2021-10-09 18:10:20] WARNING (tensorflow/MainThread) From C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\framework\op_def_library.py:263:
colocate_with (from tensorflow.python.framework.ops) is deprecated and will be removed in a future version.
Instructions for updating:
Colocations handled automatically by placer.
[2021-10-09 18:10:20] WARNING (tensorflow/MainThread) From C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\UCTB\model\ST_MGCN.py:86: dense (from tensorflow.python.layers.core) is deprecated and will be removed in a future version.
Instructions for updating:
Use keras.layers.dense instead.
[2021-10-09 18:10:20] WARNING (tensorflow/MainThread) From C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\keras\backend.py:4010: calling dropout (from tensorflow.python.ops.nn_ops) with keep_prob is deprecated and will be removed in a future version.
Instructions for updating:
Please use `rate` instead of `keep_prob`. Rate should be set to `rate = 1 - keep_prob`.
[2021-10-09 18:10:21] WARNING (tensorflow/MainThread) From C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\ops\math_ops.py:3066: to_int32 (from tensorflow.python.ops.math_ops) is deprecated and will be removed in a future version.
Instructions for updating:
Use tf.cast instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph0/multi_gcl/gcl_0/weights:0 is illegal; using CGRNN_Graph0/multi_gcl/gcl_0/weights_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph0/multi_gcl/gcl_0/biases:0 is illegal; using CGRNN_Graph0/multi_gcl/gcl_0/biases_0
instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph0/dense/kernel:0 is illegal; using CGRNN_Graph0/dense/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph0/dense_1/kernel:0 is illegal; using CGRNN_Graph0/dense_1/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph0/lstm/kernel:0 is illegal; using CGRNN_Graph0/lstm/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph0/lstm/recurrent_kernel:0 is illegal; using CGRNN_Graph0/lstm/recurrent_kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph0/lstm/bias:0 is illegal; using CGRNN_Graph0/lstm/bias_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph1/multi_gcl/gcl_0/weights:0 is illegal; using CGRNN_Graph1/multi_gcl/gcl_0/weights_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph1/multi_gcl/gcl_0/biases:0 is illegal; using CGRNN_Graph1/multi_gcl/gcl_0/biases_0
instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph1/dense/kernel:0 is illegal; using CGRNN_Graph1/dense/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph1/dense_1/kernel:0 is illegal; using CGRNN_Graph1/dense_1/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph1/lstm_1/kernel:0 is illegal; using CGRNN_Graph1/lstm_1/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph1/lstm_1/recurrent_kernel:0 is illegal; using CGRNN_Graph1/lstm_1/recurrent_kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph1/lstm_1/bias:0 is illegal; using CGRNN_Graph1/lstm_1/bias_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph2/multi_gcl/gcl_0/weights:0 is illegal; using CGRNN_Graph2/multi_gcl/gcl_0/weights_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph2/multi_gcl/gcl_0/biases:0 is illegal; using CGRNN_Graph2/multi_gcl/gcl_0/biases_0
instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph2/dense/kernel:0 is illegal; using CGRNN_Graph2/dense/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph2/dense_1/kernel:0 is illegal; using CGRNN_Graph2/dense_1/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph2/lstm_2/kernel:0 is illegal; using CGRNN_Graph2/lstm_2/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph2/lstm_2/recurrent_kernel:0 is illegal; using CGRNN_Graph2/lstm_2/recurrent_kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph2/lstm_2/bias:0 is illegal; using CGRNN_Graph2/lstm_2/bias_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name dense/kernel:0 is illegal; using dense/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name dense/bias:0 is illegal; using dense/bias_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name dense_1/kernel:0 is illegal; using dense_1/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name dense_1/bias:0 is illegal; using dense_1/bias_0 instead.
Bike NYC ST_MMGCN_DCI_K1L1_V_F5
3818
No model found, start training
Running Operation ('train_op',)
Traceback (most recent call last):
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\client\session.py", line 1334, in _do_call
    return fn(*args)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\client\session.py", line 1319, in _run_fn
    options, feed_dict, fetch_list, target_list, run_metadata)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\client\session.py", line 1407, in _call_tf_sessionrun
    run_metadata)
tensorflow.python.framework.errors_impl.InvalidArgumentError: You must feed a value for placeholder tensor 'Placeholder_3' with dtype float and shape [?,28]
         [[{{node Placeholder_3}}]]

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "ST_MGCN_Obj.py", line 122, in <module>
    batch_size=int(args['BatchSize']))
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\UCTB\model_unit\BaseModel.py", line 186, in fit
    op_names=op_names)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\UCTB\model_unit\BaseModel.py", line 91, in _run
    outputs = self._session.run(output_tensor_list, feed_dict=feed_dict_tf)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\client\session.py", line 929, in run
    run_metadata_ptr)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\client\session.py", line 1152, in _run
    feed_dict_tensor, options, run_metadata)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\client\session.py", line 1328, in _do_run
    run_metadata)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\client\session.py", line 1348, in _do_call
    raise type(e)(node_def, op, message)
tensorflow.python.framework.errors_impl.InvalidArgumentError: You must feed a value for placeholder tensor 'Placeholder_3' with dtype float and shape [?,28]
         [[node Placeholder_3 (defined at C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\UCTB\model\ST_MGCN.py:110) ]]

Caused by op 'Placeholder_3', defined at:
  File "ST_MGCN_Obj.py", line 102, in <module>
    ST_MGCN_Obj.build()
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\UCTB\model\ST_MGCN.py", line 110, in build
    external_input = tf.placeholder(tf.float32, [None, self._external_dim])
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\ops\array_ops.py", line 2077, in placeholder
    return gen_array_ops.placeholder(dtype=dtype, shape=shape, name=name)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\ops\gen_array_ops.py", line 6833, in placeholder
    "Placeholder", dtype=dtype, shape=shape, name=name)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\framework\op_def_library.py", line 788, in _apply_op_helper
    op_def=op_def)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\util\deprecation.py", line 507, in new_func
    return func(*args, **kwargs)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\framework\ops.py", line 3300, in create_op
    op_def=op_def)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\framework\ops.py", line 1801, in __init__
    self._traceback = tf_stack.extract_stack()

InvalidArgumentError (see above for traceback): You must feed a value for placeholder tensor 'Placeholder_3' with dtype float and shape [?,28]
         [[node Placeholder_3 (defined at C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\UCTB\model\ST_MGCN.py:110) ]]

Windows 10　无GPU, python==3.6 tensorflow==1.13 Keras==2.2.4 h5py==2.9.0 UCTB==0.3.0 运行文件：UCTB/Experiments/ST_MGCN/bike_trial.py 报错： 想请问一下原因？一定要使用GPU吗？
Using TensorFlow backend.
2021-10-09 18:10:20.332752: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2
[2021-10-09 18:10:20] WARNING (tensorflow/MainThread) From C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\framework\op_def_library.py:263:
colocate_with (from tensorflow.python.framework.ops) is deprecated and will be removed in a future version.
Instructions for updating:
Colocations handled automatically by placer.
[2021-10-09 18:10:20] WARNING (tensorflow/MainThread) From C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\UCTB\model\ST_MGCN.py:86: dense (from tensorflow.python.layers.core) is deprecated and will be removed in a future version.
Instructions for updating:
Use keras.layers.dense instead.
[2021-10-09 18:10:20] WARNING (tensorflow/MainThread) From C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\keras\backend.py:4010: calling dropout (from tensorflow.python.ops.nn_ops) with keep_prob is deprecated and will be removed in a future version.
Instructions for updating:
Please use `rate` instead of `keep_prob`. Rate should be set to `rate = 1 - keep_prob`.
[2021-10-09 18:10:21] WARNING (tensorflow/MainThread) From C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\ops\math_ops.py:3066: to_int32 (from tensorflow.python.ops.math_ops) is deprecated and will be removed in a future version.
Instructions for updating:
Use tf.cast instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph0/multi_gcl/gcl_0/weights:0 is illegal; using CGRNN_Graph0/multi_gcl/gcl_0/weights_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph0/multi_gcl/gcl_0/biases:0 is illegal; using CGRNN_Graph0/multi_gcl/gcl_0/biases_0
instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph0/dense/kernel:0 is illegal; using CGRNN_Graph0/dense/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph0/dense_1/kernel:0 is illegal; using CGRNN_Graph0/dense_1/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph0/lstm/kernel:0 is illegal; using CGRNN_Graph0/lstm/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph0/lstm/recurrent_kernel:0 is illegal; using CGRNN_Graph0/lstm/recurrent_kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph0/lstm/bias:0 is illegal; using CGRNN_Graph0/lstm/bias_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph1/multi_gcl/gcl_0/weights:0 is illegal; using CGRNN_Graph1/multi_gcl/gcl_0/weights_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph1/multi_gcl/gcl_0/biases:0 is illegal; using CGRNN_Graph1/multi_gcl/gcl_0/biases_0
instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph1/dense/kernel:0 is illegal; using CGRNN_Graph1/dense/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph1/dense_1/kernel:0 is illegal; using CGRNN_Graph1/dense_1/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph1/lstm_1/kernel:0 is illegal; using CGRNN_Graph1/lstm_1/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph1/lstm_1/recurrent_kernel:0 is illegal; using CGRNN_Graph1/lstm_1/recurrent_kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph1/lstm_1/bias:0 is illegal; using CGRNN_Graph1/lstm_1/bias_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph2/multi_gcl/gcl_0/weights:0 is illegal; using CGRNN_Graph2/multi_gcl/gcl_0/weights_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph2/multi_gcl/gcl_0/biases:0 is illegal; using CGRNN_Graph2/multi_gcl/gcl_0/biases_0
instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph2/dense/kernel:0 is illegal; using CGRNN_Graph2/dense/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph2/dense_1/kernel:0 is illegal; using CGRNN_Graph2/dense_1/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph2/lstm_2/kernel:0 is illegal; using CGRNN_Graph2/lstm_2/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph2/lstm_2/recurrent_kernel:0 is illegal; using CGRNN_Graph2/lstm_2/recurrent_kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name CGRNN_Graph2/lstm_2/bias:0 is illegal; using CGRNN_Graph2/lstm_2/bias_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name dense/kernel:0 is illegal; using dense/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name dense/bias:0 is illegal; using dense/bias_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name dense_1/kernel:0 is illegal; using dense_1/kernel_0 instead.
[2021-10-09 18:10:23] INFO (tensorflow/MainThread) Summary name dense_1/bias:0 is illegal; using dense_1/bias_0 instead.
Bike NYC ST_MMGCN_DCI_K1L1_V_F5
3818
No model found, start training
Running Operation ('train_op',)
Traceback (most recent call last):
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\client\session.py", line 1334, in _do_call
    return fn(*args)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\client\session.py", line 1319, in _run_fn
    options, feed_dict, fetch_list, target_list, run_metadata)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\client\session.py", line 1407, in _call_tf_sessionrun
    run_metadata)
tensorflow.python.framework.errors_impl.InvalidArgumentError: You must feed a value for placeholder tensor 'Placeholder_3' with dtype float and shape [?,28]
         [[{{node Placeholder_3}}]]

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "ST_MGCN_Obj.py", line 122, in <module>
    batch_size=int(args['BatchSize']))
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\UCTB\model_unit\BaseModel.py", line 186, in fit
    op_names=op_names)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\UCTB\model_unit\BaseModel.py", line 91, in _run
    outputs = self._session.run(output_tensor_list, feed_dict=feed_dict_tf)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\client\session.py", line 929, in run
    run_metadata_ptr)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\client\session.py", line 1152, in _run
    feed_dict_tensor, options, run_metadata)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\client\session.py", line 1328, in _do_run
    run_metadata)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\client\session.py", line 1348, in _do_call
    raise type(e)(node_def, op, message)
tensorflow.python.framework.errors_impl.InvalidArgumentError: You must feed a value for placeholder tensor 'Placeholder_3' with dtype float and shape [?,28]
         [[node Placeholder_3 (defined at C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\UCTB\model\ST_MGCN.py:110) ]]

Caused by op 'Placeholder_3', defined at:
  File "ST_MGCN_Obj.py", line 102, in <module>
    ST_MGCN_Obj.build()
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\UCTB\model\ST_MGCN.py", line 110, in build
    external_input = tf.placeholder(tf.float32, [None, self._external_dim])
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\ops\array_ops.py", line 2077, in placeholder
    return gen_array_ops.placeholder(dtype=dtype, shape=shape, name=name)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\ops\gen_array_ops.py", line 6833, in placeholder
    "Placeholder", dtype=dtype, shape=shape, name=name)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\framework\op_def_library.py", line 788, in _apply_op_helper
    op_def=op_def)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\util\deprecation.py", line 507, in new_func
    return func(*args, **kwargs)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\framework\ops.py", line 3300, in create_op
    op_def=op_def)
  File "C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\tensorflow\python\framework\ops.py", line 1801, in __init__
    self._traceback = tf_stack.extract_stack()

InvalidArgumentError (see above for traceback): You must feed a value for placeholder tensor 'Placeholder_3' with dtype float and shape [?,28]
         [[node Placeholder_3 (defined at C:\LSHApp\anaconda3\envs\tfv1\lib\site-packages\UCTB\model\ST_MGCN.py:110) ]]

您好：
UCTB支持CPU以及GPU运行，从您的报错原因上来看，是在运行时喂入external_input数据出现了问题。

authors: Liyue-Chen YnnuSL

repo: uctb/UCTB


text:
技能方向 - 数据分析与 SQL（二选一） > 课程7. [选修] SQL高级并集与性能优化 > [11. 视频：行的并集]

课程导航+地址

技能方向 - 数据分析与 SQL（二选一） > 课程7. [选修] SQL高级并集与性能优化 > 11. 视频：行的并集
第二个视频

截图
14
00:00:39,995 --> 00:00:43,870
One thing to note is, that UNION only appends distinct values.
14
00:00:39,994 --> 00:00:43,869
需要注意的是 UNION 只能添加独特的值
具体描述
“独特的”最好改为“去重后的”，因为distinct为去重操作

感谢反馈！

source: gharchive/issue

repo: udacity/band-issues-cn

license: MIT

license_type: permissive

license_source: github-api


text:
barra de progreso para arbol en presupuesto

para la seccion de aprobación presupuestal es necesario crear una barra de carga para el arbol ya que se demora, la gracia no es que lo remplace , es que aparezca arriba del arbol, esto con el fin de darle al usuario un estado de la carga del arbol

Existe un problema con los tiempos de carga que hacen muy dificil la conclusion de esta tarea, se analizo la situacion con el equipo de trabajo y se revisaron las tareas de ajuste de arbol de presupuesto, sin embargo por la construccion de la API se nos hace muy dificil seguir reduciendo los tiempos de carga. se sigue buscando solucion

El problema con respecto a los tiempos de respuesta de los endpoints ya se soluciono para poder realizar los ajustes de la barra de carga

authors: BOTOOM ManuelMurillo


text:
Cancel token

Add support for cancel token so it doesn't keep loading images even when the widget is disposed.

achievable using wrapper class

To the best of my knowledge this is not possible within the library and has to be done in the user code.

To the best of my knowledge this is not possible within the library and has to be done in the user code.

It kinda is, you can give an optional cancel token to the dio request so it can be cancelled. I have done it already so no need. You also need a widget that makes use of this.

authors: ueman xAffan


text:
bilgi/ instructions notice learning

Son kullanıcı olarak, (Yazılım bilgim bulunmamaktadır.)
Model değişimini nasıl yapabiliriz.? Seçenek belirtme olabilir mi?
Win işletim sisteminde, gerçek zamanlı olarak, mikrofondan gelen sesi nasıl yazıya dökebiliriz.?
(Win11, Gpu RTX4090, NPU, Bellek:96Gb)
Sağır olduğum için, gerçek zamanlı benim için önem taşımaktadır.
Google translate,
As an end user, (I have no software knowledge.)
How can we change the model? Is it possible to specify an option?
How can we transcribe the sound coming from the microphone in real time in the Win operating system?
(Win11, GPU RTX4090, NPU, Memory: 96Gb)
Since I'm deaf, real time is important to me.
\AppData\Local\Programs\Python\Python310\whisper_streaming>python whisper_online_server.py
INFO    Loading Whisper large-v2 model for auto...
INFO    done. It took 6.22 seconds.
WARNING Whisper is not warmed up. The first chunk processing may take longer.
INFO    Listening on('localhost', 43007)
INFO    Connected to client on ('127.0.0.1', 58827)      wait...............  There are no results

hi, see README.md. It's answered fhere.
Don't you miss client or the input for the server?

audio input from mic on windows is not documemted. I hope you find answer elsewhere

authors: Gldkslfmsd yenerismail


text:
NPM Package?

Hi,
We'd love to use this but I couldn't find an NPM package. Any chance you could publish one?
Thanks for all the great work, @christopherthielen !
Cheers

I apologize for the lack of activity.  I'll get this published and moved to its final home at @uirouter/dsr as soon as possible.  It's at the bottom of a long list of packages that need publishing including ui-router-core, angular-ui-router 1.0 final and ui-router-ng2.  They're all moving to @uirouter/* btw

any update on this?  would like to use this with ng1 as well, but also need to work through the issues discussed here: https://github.com/ui-router/sticky-states/issues/4

the other packages are now fully published under the @uirouter/* npm org.  dsr and sticky states are next

DSR has been published along with sticky states

Awesome!

authors: christopherthielen jfoo1984 mischkl

repo: ui-router/dsr


text:
no compatible Version

Hey, I totally love your app!
For some reason its not compatible with my device, a Pixel 7pro with GrapheneOS (basically Android 14).
Its an arm64 SOC. Error message:
INSTALL_FAILED_NO_MATCHING_ABIS: INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res=-113

Hi,
Would this be with the arm64-v8a build by any chance?

This sounds like a GrapheneOS issue, on my Motorola G31(w) running Android 14 GSI, the arm64-v8a build installs fine.
miklos_akos@YiffBook-Pro Downloads % adb install qrserv-v2_1_6-arm64-v8a.apk
Performing Streamed Install
Success
miklos_akos@YiffBook-Pro Downloads % adb shell getprop | grep "ro.product.build.version\|ro.product.model\|abilist"
[ro.product.build.version.incremental]: [eng.ponces.20231020.203236]
[ro.product.build.version.release]: [14]
[ro.product.build.version.release_or_codename]: [14]
[ro.product.build.version.sdk]: [34]
[ro.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]
[ro.product.cpu.abilist32]: [armeabi-v7a,armeabi]
[ro.product.cpu.abilist64]: [arm64-v8a]
[ro.product.model]: [moto g31(w)]
[ro.system.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]
[ro.system.product.cpu.abilist32]: [armeabi-v7a,armeabi]
[ro.system.product.cpu.abilist64]: [arm64-v8a]
[ro.vendor.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]
[ro.vendor.product.cpu.abilist32]: [armeabi-v7a,armeabi]
[ro.vendor.product.cpu.abilist64]: [arm64-v8a]
miklos_akos@YiffBook-Pro Downloads %

Hi,
Would this be with the arm64-v8a build by any chance?

Yes, this version works!

authors: firefoxlover miklosakos uintdev

repo: uintdev/qrserv


text:
Doesn't support BZIP2 compression

Can't unzip an archive created with python build-in compress_type=ZIP_BZIP2, compress_level=9:
File "/Users/trofiv/Projects/trofiv/es-backup/venv/lib/python3.9/site-packages/stream_unzip.py", line 424, in stream_unzip
   for file_name, file_size, unzipped_chunks in all():
 File "/Users/trofiv/Projects/trofiv/es-backup/venv/lib/python3.9/site-packages/stream_unzip.py", line 416, in all
   yield yield_file(yield_all, get_num, return_num_unused, return_bytes_unused, get_offset_from_start)
 File "/Users/trofiv/Projects/trofiv/es-backup/venv/lib/python3.9/site-packages/stream_unzip.py", line 376, in yield_file
   raise UnsupportedCompressionTypeError(compression)
stream_unzip.UnsupportedCompressionTypeError: 12

Sounds reasonable so far, and it doesn't need too much more code from my initial investifation. I have added it in https://github.com/uktrade/stream-unzip/pull/40 if you want to give it a test?

Works like a charm! Thank you very much for such rapid work done!

No problem!
Now released in v0.0.83:

https://pypi.org/project/stream-unzip/0.0.83/
https://github.com/uktrade/stream-unzip/releases/tag/v0.0.83

repo: uktrade/stream-unzip


text:
TP-541: Prevent deletion of linked quotas.

Quota Associations, Quota Suspensions and Quota Blocking
Periods all demand that their linked quotas be live. I.e.
the linked Quota Definitions can not be deleted until the
relevant associations, suspensions and blocking periods
either refer to a different quota or are deleted themselves.
This commit introduces a business rule to check that any
quota being deleted cannot be referred to by an association,
suspension or blocking period.

Codecov Report

Merging #216 (3dd67ed) into master (b47d49a) will increase coverage by 0.01%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master     #216      +/-   ##
==========================================
+ Coverage   61.12%   61.13%   +0.01%
==========================================
  Files         177      177
  Lines       10736    10763      +27
  Branches      805      811       +6
==========================================
+ Hits         6562     6580      +18
- Misses       3991     3997       +6
- Partials      183      186       +3

Impacted Files
Coverage Δ

quotas/models.py
2.27% <ø> (ø)

quotas/business_rules.py
25.42% <50.00%> (+4.42%)
:arrow_up:

quotas/tests/test_business_rules.py
94.38% <100.00%> (+0.29%)
: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 b47d49a...3dd67ed. Read the comment docs.

source: gharchive/pull-request

authors: NDevox codecov-io

repo: uktrade/tamato


text:
Vuepress fails to run after setting theme

I installed @vuepress/blog as the readme explains, and set the theme in config.js,
module.exports = {
  title: 'Hello VuePress!',
  description: 'Just playing around',
  theme:'@vuepress/blog',
  themeConfig:{
  }
}

then ran vuepress dev. I got:
 /m/c/p/v/d/test3 vuepress dev                                                                                09:55:11
Extracting site metadata...Error: [vuepress] Failed to load custom theme "@vuepress/blog". File vuepress-theme-@vuepress/blog/Layout.vue does not exist.
    at resolveOptions (/home/ray/.npm-global/lib/node_modules/vuepress/lib/prepare.js:132:15)
    at prepare (/home/ray/.npm-global/lib/node_modules/vuepress/lib/prepare.js:37:25)
    at dev (/home/ray/.npm-global/lib/node_modules/vuepress/lib/dev.js:21:25)
    at args (/home/ray/.npm-global/lib/node_modules/vuepress/bin/vuepress.js:104:12)
    at Command.program.command.description.option.option.action (/home/ray/.npm-global/lib/node_modules/vuepress/bin/vuepress.js:31:21)
    at Command.listener (/home/ray/.npm-global/lib/node_modules/vuepress/node_modules/commander/index.js:315:8)
    at Command.emit (events.js:182:13)
    at Command.parseArgs (/home/ray/.npm-global/lib/node_modules/vuepress/node_modules/commander/index.js:651:12)
    at Command.parse (/home/ray/.npm-global/lib/node_modules/vuepress/node_modules/commander/index.js:474:21)
    at Object.<anonymous> (/home/ray/.npm-global/lib/node_modules/vuepress/bin/vuepress.js:96:9)

Sorry, my vuepress CLI was out of date.

repo: ulivz/vuepress-theme-blog


text:
Translation wiki to russian and names correction

I've checked this nomenclature with iupac recommendations.
Some chemical elements changed it's names.
[http://www.chem.qmul.ac.uk/iupac/AtWt/table.html]
Correct this values please.
Ununtrium - Nihonium
[https://en.wikipedia.org/wiki/Nihonium]
Ununpentium - Moscovium
[https://en.wikipedia.org/wiki/Moscovium]
Ununseptium - Tennessine
[https://en.wikipedia.org/wiki/Tennessine]
Ununoctium - Oganesson
[https://en.wikipedia.org/wiki/Oganesson]
[https://en.wikipedia.org/wiki/Periodic_table]
values-ru.zip

Thanks for pointing out the error in the wiki. The names have been updated.

Can you also translate the store description?

[title]
Elementary: периодическая таблица
[keywords]
Science
Chemistry
Elements
Periodic Table
[short-description]
Периодическая таблица элементов с  открытыми исходными кодами.
[description]
Периодическая таблица элементов с  открытыми исходными кодами.
Особенности:

масштабируемая периодическая таблица элементов
нажмите на элемент для получения базовой информации
лёгкий доступ к Wikipedia и YouTube видео в описании элемента
бесплатно и без рекламы!

видео  предоставляется Periodic Videos (http://www.periodicvideos.com/)
Лицензия The MIT License
Исходные коды доступны: https://github.com/ultramega/elementary
Twitter: https://twitter.com/ultramegasoft
Facebook: https://www.facebook.com/ultramegasoft
Google+: https://plus.google.com/+UltraMegaSoftware

Translated store.txt

Are the keywords meant to be in English?

[keywords]
Наука
Химия
Элементы
Периодическая таблица
Периодическая система Менделеева
Менделеев

I think that covers everything. Thanks for the contribution.

authors: ashed ultramega

repo: ultramega/elementary


text:
Support uploading and downloading message attachments

Users should be able to attach files to their messages, and download attachments from messages in the scrollback.

There will need to be a way to remove attachments from a message if the user changes their mind, or attaches the wrong thing.

repo: ulyssa/iamb


text:
Add support for vector registers.

This PR also makes a small fixes:

in telamon-gen: universal quantifiers where not processed in the right order when
some quantified sets had parameters.
in variables.exh: some set definitions where wrong but not used before

bors retry

bors r-

bors r+

bors r+

bors r+

authors: nicoTolly ulysseB

repo: ulysseB/telamon


text:
Comparison alternatives

Hi,
I found umbrella and it looks nice, but at the moment to much modules / plugins have a jQuery dependency to move away... 👎
Maybe the comparison table could be interesting (German link...)?
https://nerdkrams.de/6-leichtgewichtige-jquery-alternativen-im-funktionsvergleich/
I played with Minified.js which is really nice and a full jQuery replacement looked at the functionalities.
And recently found kimbo.js

What do you mean? There is no jquery dependency at all, it is just there for testing Umbrella JS speed against jQuery, but of course there is no jQuery in the production code.

Not  umbrella have jquery dependencies, but many published things (lightboxes, sliders, menu / nav). So it isn't easy to move from jquery to umbrella vor any other framework.
But umbrella - as other alternatives too - is great work!
I would love to see jquery replaced by a smaller solution in the future.

Ah thanks! However it is not a jQuery replacement, for that there are few alternatives like Zepto.js
Umbrella's goals are to help you with development in a similar way to jQuery, but not to replace it totally.

authors: franciscop pwFoo

repo: umbrellajs/umbrella

license: mit

license_source: bigquery


text:
Add reference to software being open source

Consider adding, were appropriate, a statement in regard to “open source.” I believe there is an expectation that the deliverable will open source software.

Added in 2.3 Deployment Plan

authors: mdconatser shaneknows


text:
Moving from Jet to our own code generator mechanism

JET has been a major technology for model-to-text transfomration, but its development has been stopped because of some diffuculties that developers have to deal with (maybe). Furthermore, we are getting so many issues reagding keeping its integration into Umple.
We would like to get ride of JET and transform all of the JET templates to our own code generation language.

Comments From @TimLethbridge

Jet generates files that do the generation for each language; these files call java(Umple) methods to fine-tune generation.
There is a Nebua framework developed by Umple team that uses its own templates to generate code along with 'generation points' for decision making. We don't have good documentations for this framework yet. We have separately used our inbuild templating for some other generators e.g. state tables. We know that works well.
I think it ought to be possible to simply replace a Jet template with a version of the same template simply translated into our language. It would be best yet if this translation can be automated (wholy or partly) to prevent the need to do this (semi-)automatically; but Jet creates files in specific formats, and the issue of how Umple's output would be able to substitute for this would need to be addressed.

Experimented quite a bit with JET and the built in Umple Template.
To clarify the terminology so I don't confuse myself or anyone else, since there are two different stages of generated code:
The templates will be transformed into generated Java code, which is stored in the repository. Then, this generated Java code is used by the rest of Umple to generate source code in various languages. So:
template(s) refers to the JET/Umple templates
generated code refers to the Java code generated from the templates
source code refers to the code that is generated by Umple not related to templates, and it is made by compiling code written in Umple
(I don't refer to code written by hand in umple, so don't have a term for it)
If someone has suggestions about better names, please say so, I think this will help.
General Overview
It is definitely possible to use the Umple templating to generate the same general structure of classes and calls used in JET. However, without significant parsing of the dependencies between and inside each template (to get the parameters), the solution will be semi-automatic due to the function calls issue I discuss lower.
Little introduction:
If you are unfamiliar with the JET templates, see this existing template.
I then transformed it to be an Umple template.
- The code generated by this template will not run, since it is missing some of the variable types that are needed. If the code generated were to be hooked up to the rest of Umple, I believe the source code it would generate would be very close, but I have not tried to generate any source code from it.
One big difference with JET and Umple will be that the Umple will use significantly more function calls, which will make the generated code more readable and make determining which templates are used were easier. As well, the Umple template appears to be more verbose and would be more difficult to write, due to needing to not being able to handle inlining java code (see Handling <% ... %> for an example).
Basic transformation
We use a few JET syntaxes that need to handled when converting:

Everything outside of the <%....%> can be used directly in the Umple template, but it may need to be broken up, see below.
<%= java code whose result is to be placed into source code%>: This is very simple to handle, since just need to change to <<= ... >>.
<% some java code %>: This code is to be placed into the generated code that will be created, and will not be inserted into the created source code. It needs to be handled specially, since the current Umple template doesn't allow inlining of generated code like this. See Handling `<% ... %> for a better description, and my solution.
<%@ include file="someJetFile.jet"%>: From my understanding, this should be able to be directly transferred to a function call in the same way that the java code will be. This will create most of the difficulties, for reasons I will explain below

Handling <% ... %>
In JET template:
Text before
<% if (addSpace) {%>
    Text in
<% } %>
Text after

will cause the generated code to be (approximately):
stringBuilder.append("Text before");
if (addSpace) {
    stringBuilder.append("Text in")
}
stringBuilder.append("Text after");

However, there is no direct translation to Umple templates. Instead, with the current abilities of the Umple templates, would need to do (approximately):
templatePart1 <<! Text before !>>
templatePart2 <<! Text in !>>
templatePart3 <<! Text after !>>

emit genPart1(...)(templatePart1);
emit genPart2(...)(templatePart2);
emit genPart3(...)(templatePart3);

void generate(...)
{
      _genPart1(...);
      if (addSpace) {
         genPart2(...);
     }
     genPart3(...);
}

This will make the difficulty involved with function calls worse, due to there being more function calls in Umple templates. Also makes the template harder to write and understand.
Difficulties

Function calls: With the JET templates, parameters are not specified for most of the templates. Instead, all of the .jet templates are essentially injected, directly or indirectly, into the .jumpjet files which are converted into the classes that Umple will then call. This means that the JET templates are put into a few massive functions. It looks like all the functions called by the generated code are declared in the .jumpjet files.

As far as I can tell, however, there is no possibility of inserting one of the Umple templates directly into java code, instead they are created using the emit syntax, which will generate a function to be called.
This means the greatest difficulty with converting the JET templates automatically will be determining the arguments to each template, as well as their types.
It appears that most, possibly all, of the common names for variables used in the JET templates (like av, used for some descendents of UmpleVariable) are used for just one type. However, there are some that occur more rarely, mostly booleans and ints.

Name mangling: Since the Umple templates will need to be generated into the same class as the JET templates are, will need to have multiple templates belonging to the same class (although may split up different types, like association or setters into sub-classes). Since the templates will not be differentiable by name for the Umple compiler, will need to ensure that their names are different.

The solution I would default to would be to prefix all functions related to a single template with the file name. EG: association_SetOneToOptionalOne_templatePart1 or SetOneToOptionalOne inside of the Association class, depending on the overall organization.

Useful to have added
The addition to Umple that would make this task far easier would be adding the option of inlining of code in two different ways:

Allowing code to be embedded in the template, like how JET handles <% .... %>.

This would make handling <% .... %>  trivial, although I outlined an alternative above. See Handling <% some java code %> for details.
As well, it may make it easier to write template, although that would depend on opinion.

Allow request for regular functions, when vcompiling with Umple. Would need to be possible without giving arguments for those functions.

For the conversion from JET,
If it were possible to inline all templates and functions, without needing to give parameters to the ones that will be inlined, then the function calls difficulty would be eliminated completely.

Of course, I do not expect that this would be trivial, or even worthwhile, but it would be an option.
There were some other minor issues I encountered with the Umple templating, but I will create an issue for them.
Questions

Are there any parts of my explanation that are unclear?
How should I approach the overall task?

Depending on the design of the Umple complier, I may be able to use parts of it to make this translation easier, although that may be too complex.
It would be possible to throw together a semi-automatic script in a few hours/days that would be able to convert most of the templates without dealing with the function calls difficulty. However, there would be a lot of boring determining which arguments are missing.
The more detailed the approach (eg: just missing the type for the arguments), the longer the script would take to make.

How should I approach the function calls issue?
Is there an alternative to how I proposed could handle the name mangling issue?

I will convert at least one more template, probably one of the ones that is more responsible for determining which of the other JET template files should be used, like association_SetOneToOptionalOne or association_SetOneToOptionalN.

Regarding the transformation from Jet to Umple TL for the case of if statement with text before and after,:

Handling <% ... %>
In JET template:
Text before
<% if (addSpace) {%>
Text in
<% } %>
Text after
will cause the generated code to be (approximately):
stringBuilder.append("Text before");
if (addSpace) {
stringBuilder.append("Text in")
}
stringBuilder.append("Text after");
However, there is no direct translation to Umple templates. Instead, with the current abilities of the Umple templates, would need to do (approximately):
templatePart1 <<! Text before !>>
templatePart2 <<! Text in !>>
templatePart3 <<! Text after !>>
emit genPart1(...)(templatePart1);
emit genPart2(...)(templatePart2);
emit genPart3(...)(templatePart3);
void generate(...)
{
_genPart1(...);
if (addSpace) {
genPart2(...);
}
genPart3(...);
}

I believe it can done as the following:
in JET:
Text before
<% if (...) {%>
Text in
<% } %>
Text after
In Umple TL:
<<! Text before
<<# if (...) {#>>
Text in
<<# } #>>
Text after
!>>
Sultan

On Feb 2, 2016, at 11:30 PM, Morgan Redshaw notifications@github.com wrote:
Experimented quite a bit with JET and the built in Umple Template.
To clarify the terminology so I don't confuse myself or anyone else, since there are two different stages of generated code:
The templates will be transformed into generated Java code, which is stored in the repository. Then, this generated Java code is used by the rest of Umple to generate source code in various languages. So:
template(s) refers to the JET/Umple templates
generated code refers to the Java code generated from the templates
source code refers to the code that is generated by Umple not related to templates, and it is made by compiling code written in Umple
(I don't refer to code written by hand in umple, so don't have a term for it)
If someone has suggestions about better names, please say so, I think this will help.
General Overview
It is definitely possible to use the Umple templating to generate the same general structure of classes and calls used in JET. However, without significant parsing of the dependencies between and inside each template (to get the parameters), the solution will be semi-automatic due to the function calls issue I discuss lower.
Little introduction:
If you are unfamiliar with the JET templates, see this existing template https://github.com/umple/umple/blob/aa2ac20ea79a9437d09cbe60454b380e8bbaa719/UmpleToJava/templates/association_SetOneToOptionalOne.jet.
I then transformed it to be an Umple template http://pastebin.com/9Ca8Xynh.

The code generated by this template will not run, since it is missing some of the variable types that are needed. If the code generated were to be hooked up to the rest of Umple, I believe the source code it would generate would be very close, but I have not tried to generate any source code from it.

One big difference with JET and Umple will be that the Umple will use significantly more function calls, which will make the generated code more readable and make determining which templates are used were easier. As well, the Umple template appears to be more verbose and would be more difficult to write, due to needing to not being able to handle inlining java code (see Handling <% ... %> for an example).
Basic transformation
We use a few JET syntaxes that need to handled when converting:
Everything outside of the <%....%> can be used directly in the Umple template, but it may need to be broken up, see below.
<%= java code whose result is to be placed into source code%>: This is very simple to handle, since just need to change to <<= ... >>.
<% some java code %>: This code is to be placed into the generated code that will be created, and will not be inserted into the created source code. It needs to be handled specially, since the current Umple template doesn't allow inlining of generated code like this. See Handling `<% ... %> for a better description, and my solution.
<%@ include file="someJetFile.jet"%>: From my understanding, this should be able to be directly transferred to a function call in the same way that the java code will be. This will create most of the difficulties, for reasons I will explain below
Handling <% ... %>
In JET template:
Text before
<% if (addSpace) {%>
Text in
<% } %>
Text after
will cause the generated code to be (approximately):
stringBuilder.append("Text before");
if (addSpace) {
stringBuilder.append("Text in")
}
stringBuilder.append("Text after");
However, there is no direct translation to Umple templates. Instead, with the current abilities of the Umple templates, would need to do (approximately):
templatePart1 <<! Text before !>>
templatePart2 <<! Text in !>>
templatePart3 <<! Text after !>>
emit genPart1(...)(templatePart1);
emit genPart2(...)(templatePart2);
emit genPart3(...)(templatePart3);
void generate(...)
{
_genPart1(...);
if (addSpace) {
genPart2(...);
}
genPart3(...);
}
This will make the difficulty involved with function calls worse, due to there being more function calls in Umple templates. Also makes the template harder to write and understand.
Difficulties
Function calls: With the JET templates, parameters are not specified for most of the templates. Instead, all of the .jet templates are essentially injected, directly or indirectly, into the .jumpjet files which are converted into the classes that Umple will then call. This means that the JET templates are put into a few massive functions. It looks like all the functions called by the generated code are declared in the .jumpjet files.
As far as I can tell, however, there is no possibility of inserting one of the Umple templates directly into java code, instead they are created using the emit syntax, which will generate a function to be called.
This means the greatest difficulty with converting the JET templates automatically will be determining the arguments to each template, as well as their types.
It appears that most, possibly all, of the common names for variables used in the JET templates (like av, used for some descendents of UmpleVariable) are used for just one type. However, there are some that occur more rarely, mostly booleans and ints.
Name mangling: Since the Umple templates will need to be generated into the same class as the JET templates are, will need to have multiple templates belonging to the same class (although may split up different types, like association or setters into sub-classes). Since the templates will not be differentiable by name for the Umple compiler, will need to ensure that their names are different.
The solution I would default to would be to prefix all functions related to a single template with the file name. EG: association_SetOneToOptionalOne_templatePart1 or SetOneToOptionalOne inside of the Association class, depending on the overall organization.
Useful to have added
The addition to Umple that would make this task far easier would be adding the option of inlining of code in two different ways:
Allowing code to be embedded in the template, like how JET handles <% .... %>.
This would make handling <% .... %> trivial, although I outlined an alternative above. See Handling <% some java code %> for details.
As well, it may make it easier to write template, although that would depend on opinion.
Allow request for regular functions, when vcompiling with Umple. Would need to be possible without giving arguments for those functions.
For the conversion from JET,
If it were possible to inline all templates and functions, without needing to give parameters to the ones that will be inlined, then the function calls difficulty would be eliminated completely.
Of course, I do not expect that this would be trivial, or even worthwhile, but it would be an option.
There were some other minor issues I encountered with the Umple templating, but I will create an issue for them.
Questions
Are there any parts of my explanation that are unclear?
How should I approach the overall task?
Depending on the design of the Umple complier, I may be able to use parts of it to make this translation easier, although that may be too complex.
It would be possible to throw together a semi-automatic script in a few hours/days that would be able to convert most of the templates without dealing with the function calls difficulty. However, there would be a lot of boring determining which arguments are missing.
The more detailed the approach (eg: just missing the type for the arguments), the longer the script would take to make.
How should I approach the function calls issue?
Is there an alternative to how I proposed could handle the name mangling issue?
I will convert at least one more template, probably one of the ones that is more responsible for determining which of the other JET template files should be used, like association_SetOneToOptionalOne or association_SetOneToOptionalN.
—
Reply to this email directly or view it on GitHub https://github.com/umple/umple/issues/708#issuecomment-179000879.

Good work so far. Answers to your questions:

Are there any parts of my explanation that are unclear?

I think that it is good. Thanks

Is the change to the Umple templates possible, and worth it?

Yes, possible. @ahmedvc is the key contact. He is in the middle of submitting his thesis, but can certainly fix bugs and has been responsive on previous issues. Whether or not worth it needs determining.

If not, how should I approach the function calls issue?

Will let @ahmedvc answer this and your other questions above.

An emitter method doesn't require arguments for for every specialized template. Also, we use <<= >> to ensure that the response will be added to the text emitted.
The correct code should be:
class GeneratorForLanguage
{
      association_SomeSpecializedTemplate <<! ... !>>
      private emit association_SomeSpecializedTemplate()(association_SomeSpecializedTemplate);

      // The template that determines which of the templates to call
      baseTemplate <<! ...
             // Some way to reference the existing template, exact character could be changed
             <<=association_SomeSpecializedTemplate()>>
       !>>

       // There would only be one or two functions that are called like this, so easy to determine for them.
         // The main entry points
      emit genCode(known arguments..)(template);
      public void generateCode(arguments....)
      {
            genCode(arguments...);
      }
}

A2:
Yes, it is possible to support referencing to template attributes inside template, but I avoided doing it for the following reasons:
1- Text emission duplication: if two classes reference the same template attribute. The generated text will duplicate that attribute text for both classes. Consider the following example:
-With Reference support
class SharedTemplates {
  t1 <<! text 1 !>>
  emit t1()(t1);
}

class T1 {
  text <<! <<@SharedTemplates.t1@>>  !>>
  emit text()(text);
}

class T2 {
  text <<! <<@SharedTemplates.t1@>>  !>>
  emit text()(text);
}

-Without Reference support
class SharedTemplates {
  singleton;
  t1 <<! text 1 !>>
  emit t1()(t1);
}

class T1 {
  text <<! <<=SharedTemplateHelper.getInstance().t1()>>   !>>
  emit text()(text);
}

class T2 {
  text <<! <<=SharedTemplateHelper.getInstance().t1()>>   !>>
  emit text()(text);
}

2- Text formatting and space handling: the text will be generated on the umple compiler side, and injected directly. So, there is no emitter method and it is not possible for example to change indentation.
A3:
The emitter function can have the same name a template attribute has. Template attribute text is only generated when it is referenced by an emitter method. We do that to avoid generating unnecessary text. The emitter method doesn't require a specialized arguments.
t1 <<! ... !>>
private emit t1()(t1);

t1 <<! ... !>>
private emit t1()(t1);

t2 <<! <<=t1()>> !>>
emit t2()(t2);

It is also possible to associate a list of template attribute to the same emitter function.
t1 <<! ... !>>
private emit t1()(t1);

t2 <<! <<=t1()>> !>>
emit t2()(t2);

emit t3()(t1,t2);

It is also possible to associate a shared template attribute with an emitter method:
class SharedTemplateHelper {
  singleton;
  copyright <<! copyright text !>>
  test1 <<! test 1 !>>
  end <<! end !>>

  emit copyright()(copyright);
  emit testText()(test1);
  emit end()(end);
}

class Test
{
  commentedCopyright <<!
          /////////////////////////////////////
          <<=SharedTemplateHelper.getInstance().copyright()>>
          /////////////////////////////////////
   !>>

  emit introCopyright()(commentedCopyright,
   SharedTemplateHelper.test1,
   SharedTemplateHelper.end);
}

A4: Semi-automatic script does make sense. There should be no problem with function calls, just create empty arguments emitter functions, so you don't need to specify any arguments.
A5: There should be no issue with name mangling, as we can have the same template name for an emitter method.

I think using the umple template engine is a great idea, I will throw out a devil's advocate here though for using FreeMarker. Just something to consider.

@SultanEid Yea, I had noticed that around 5 minutes after I posted this issue.....
@amidzak
A1:

Also, we use <<= >> to ensure that the response will be added to the text emitted.

Both using <<=gen()>> and <<# _gen(0, stringBuilder)#>> would cause the same source code to be generated. In the future, I would probably use the <<= >> like you did since it would be easier to read.
Sorry, I guess I didn't explain the issue enough. Using some code from the template I had given in my example:
class Generate
{
  template <<!public function <<=gen.translate("setMethod",av)>>($<<=gen.translate("parameterNew",av)>>)
  {
    $wasSet = false;
    ....
    return $wasSet;
  }!>>

      emit runTemplate()(template);
      public void generateCode(gen, av)
      {
            runTemplate();
      }
}

While it is possible for emit runTemplate()(template) to be set up with no arguments, when run it will generate:
  public StringBuilder _runTemplate(Integer numSpaces, StringBuilder sb){
  ...
  realSb.append(gen.translate("setMethod",av));
  ...
  }

So the issue is that in the generated function, while the function would not declare any arguments, it would still use some variables that are needed. So if the variables are not included in the function declaration, they would need to be members of the generated class. However, there are a large number of different variables, and many are declared in Java's for each, which requires the (VarType varName : iteratedThrough).
A2:
Ok, may not be a great idea to add this functionality then.
A3:
This relates to A1, but knowing that the emitted function can have the same name would make things easier. Same with the shared template attribute, so thanks for the information!
A4:
Again, relates to the different interpretation of A1.
A5: Yea, I believe I had overestimated this issue, and it should be a non-factor.

I see your point. It is a matter of referencing multiple templates directly that have the same context. However, the current way enforces better practices, since developers will be aware of which variables each template requires when they write an emitter method for it. When constructing a template from many templates, at some point, when debugging a very complicated one, we may end up with a situation where we do not know which variable belongs to which template.
I still do not mind the new way, although I am reluctant that it will open the door for an undesired level of complexity. The good part is that it will be nice to reduce the number of the emitter methods to be defined.
A work item may be needed to track this item. I see that at the moment, it is not major, since the current features won't stop someone from developing their templates.
The proposed syntax will have an example like the following:
class Shared {
  result1 <<! num = <<=varI>> !>>
  result2 <<! num = <<=varJ>> !>>
}
class SharedTemplateHelper {
  result3 <<! ... !>>
  result <<!
  <<@Shared.result1>>
  <<@Shared.result2>>
  <<@result3>>
  !>>
  emit result(int varI , int varJ)(result);
}

With the current features, it will be as below. The difference is mainly about additional emitter methods and having the same context (variables,.., etc.) for a group of referenced templates.
I hope that I addressed what you are looking for. If no, please let me know. In the mean time, you should be able to use the current way we have until I get back to it.

I totally agree that not being able to insert a template would enforce better coding practices. It can be really difficult to understand the existing templates, since there is no way to know most of the variables they use.
It would be completely possible to convert the JET templates to Umple's without this feature, but it would be far easier to convert if the feature existed. The templates would honestly be easier to understand without the feature.
As for if it should be added, I don't really have strong feelings either way. The only advantage for implementing it would be to make translating from JET easier.

So my plan for right now is to assume that referencing templates inside of other templates will not be implemented.
So I will work on translating the JET to Umple's templates, and work on determining the arguments to each template.
As I had mentioned earlier, pursing this will allow differing complexity levels for the input script, ranging from it only converting basic syntax, and requiring determining the parameters for each template, and their types, to a fully automated script, that would parse all of the templates for the parameters needed any their types.
For now, I will aim for creating a program that will be able to convert the general parts of the template, and determine the parameters to each template, but will need the user to determine the actual types. What this will require is:

Basic string parsing, to convert the <%, %>, and all of the specialized versions to their counterpart in Umple template.
Some more advanced parsing of the Java code contained in the templates (within <%= and <%) to determine what parameters are used in each template. Will not be examining where the template is referenced to determine their type.

To start with, I will look at the core for Umplificator to find the best way to parse the Java code, since I don't want to have to write the parser for Java. If anyone knows any better or more specific places to look at, please say so.

Miguel Garzon @mgarzon may comment regarding the last comment.

You may have a look at Umple internal parse because we are going to take it out and consider it as a separate project. Therefore, it might be useful

There should be a pull request coming from ahmevc 'any time now' to support templates within templates.

Umple now allows embedded templates using <<@ temp name >>

One thing of important note: We need to thoroughly document speed and memory usage with Jet and make sure we are not getting significantly worse performance on a large compile (e.g. Master.ump) when we cut over to our new approach, as per #720

Ok, so I have started to work on the converter from JET to Umple.
Right now, it is able to convert most of the major elements of JET templates to their equivalent in Umple.
However, there is still quite a bit of functionality missing, especially creating emit statements, and parsing the JET directive at the beginning of each template, which have some important information in it.
There are some differences between how our template handles code blocks (<<#) and how JET handles them. I outlined this in issue #732, but our template generator treats the whitespace around the code blocks differently. While this can be worked around for the templates, I feel that how JET handles it is more intuitive.
One other important difference is how Umple's templates will be generated as static, while JET doesn't. We will need to ensure this doesn't hurt the speed/memory usage when compiling.
There is still a lot that needs to be done, but after altering the code blocks by hand (can be done automatically, but want to determine if we will change how we handle them first) I was able to insert a basic template that was converted, then generated by UMple, into the JET compiled templates and pass all the tests.

OK. Excellent progress.

After a bit more work, I was able to work around the code blocks issue (#732). I still think it should be fixed, but I am able to convert basic templates with no problem.
As well, I was able to convert a small group of templates (where one imported a few other templates) and , after some further adjustments to my converter, I was able to replace the JET generated code for them with the Umple generated version.
However, when I tried to convert all of the JET templates for Umple, I would get an error that 'phpClassGenerator' can not cyclically refer to 'UmpleToPhp.constructor_Declare_All'. After some investigation, discovered issue #736, and I will not be able to proceed farther with testing the overall conversion until this issue is resolved.
I can still work on other things for the conversion, like parsing the JET directives at the beginning of a template, but will not be able to see if the converter works for all of the templates yet.
While working on it, I found a few minor issues with the converter (like #735).

I wonder if you could convert without error UmpletoJava generator?

Didn't actually try working with the other language generators.....
UmpleToJava encounters the same error, and I would expect that UmpleToRuby does as well, but my converter actually encounters an infinite loop for UmpleToRuby, so will need to look into it some more.

Ahmed and Mahmoud are working on a pull request (they are at a conference that has just finished). They hope to commit it later today to fix some of the issues related to this such as #736

It has been a very busy day for the templates! They fixed the two major issues that I had (#736 and #735), and essentially fixed #732.
After removing the hacks I had added for #732 I was able to compile the templates..... And all of the php generation tests failed. The good news is that they all fail on the first line in the files (and then the third), so there are at least some common issues.
It looks like there are a few special cases that I have not handled (as well as possibly some weird behavior from JET). While I believe that it will be best for the converter to handle these issues, I have not closed #732 since I do not know for sure what all of the remaining differences are.
Also, I will not be able to work much on Umple tomorrow (Sunday) due to being in a hackathon for most of the day. Will hopefully be able to investigate a bit more before our meeting on Monday, although that is not guaranteed.

I believe the translation will ultimately be semi-automatic, because of things like JET removing the newline for the first text printed, but most of the translation will be automatic, so should be easy to translate the other templates. I will spend up to one and a half more weeks on the converter, then will need to work on finalizing the translation for all of the Umple templates, adding extra documentation to the converter and improving the tests, and getting the converting into the repository.
Currently, it will fail 114 out of the 237 tests that php has, although a few minor changes (like not adding a newline to the first text) must be performed by hand to the template. Of course, many of these tests will fail due to similar issues, so there is not as much work required as the number of tests would suggest.
I can understand why JET has fallen out of favor, because there are quite a few special cases, especially focused around } and the end of code blocks.
Due to all of these special cases, I have also create a small test suite for the converter. The main tests I have now are for certain special cases (like those around }) that the converter should handle. Since I may mistaken the special cases, I am also checking that none of the previously checked templates have changed when translated as well.
I have run into an error for Umple around comments (issue #763), but there is an easy workaround and so it isn't a high priority right now.

I worked a lot on being able to convert the templates this last week, and will now be able to begin integrating using Umple templates instead of JET for the regular build.
In the meeting last week, I mentioned that some of the Java tests would fail due to them requiring tests. After a little investigation, it turned out there was one line in the Java JET templates that included a tab which would be put into the source code. So after changing the tests to expect the correct number of spaces, 156 Java tests were fixed. I believe there are also some tabs for the Ruby JET templates that I have also removed.
I had also mentioned an issue with spacing, that JET would create extra spaces on certain lines, but my converter wouldn't. The differences mostly occurred between functions (although could also be inside a function), where a line from JET would just include two unnecessary spaces.  An example of this is from the Java implementation test, 'ClassTemplateTest_Import.java.txt', which at one point expected:
'''
return wasSet;
}
// Two spaces on this blank line, between the functions
public void delete()
{

By changing what was expected for this test, and a few others, I was able to get all tests to pass for Java (ClassGenerator, InterfaceGenerator, and SpecGenerator) and get all tests to pass for Php (ClassGenerator and InterfaceGenerator).

Also, after adding a bit of functionality to the converter, I was able to replace the generated code for Ruby, and pass all the tests. I had to make some changes to the tests (which I feel improved the Ruby output), because of Ruby implementation tests like the one for ClassTemplateTest_Attributes.ruby.txt, which expected:

def Mentor::get_with_id(a_id)
@mentors_by_id[a_id]
end
def Mentor::has_with_id?(a_id)
get_with_id(a_id) != nil
end
def get_p
@p
end

which had no blanklines between functions, unlike almost all other Umple tests.

So right now, all tests pass for Java, PHP and Ruby, when taking the generated code that Umple would create, and replacing JET's generated code. All I will need to do then is set it up so the Umple templates are hooked into the build process, rather than needing to copy their generated code into Umple by hand.

One possible issue, however, is I noticed that some templates for Java are not tested. I cannot remember off the top of my head some examples, but I will look for them early this week. I believe they are in JavaSpecGenerator, and I noticed these due to changing the tabs to spaces, but not needing to change any tests to handle this.

I also found a difference between how Umple handles including templates vs how JET does. While I do think Umple's is easier to think about, it will temporarily make our templates harder to read. I will create an issue about this within the next few hours.

Excellent progress. If all existing tests pass, and the full build passes, I think that should be sufficient. If there are some non-tested templates, it might be good for you to raise an issue specifying the places where tests need adding.
Tim

Can you do a performance test now where you compile Umple a few times using a version of the compiler in which you have generation from UmpleTL, and compare it to performance using Jet. Similarly, please compare testing time with the two versions. We want to ensure there isn't a significant hit.

excellent work @Diusrex

As we discussed in the UCOSP meeting this morning, in the next few days I will:

Create a pull request to fix some of the tabbing issues and space issues that can be fixed in JET. As I had mentioned earlier, there are a few lines with tabs, and some lines separating functions will have extra spaces. The templates that will be changed are:

Java templates: toString_declare.jet, most (possibly all) java template that ends with a }, followed by a non-blank line (like association_AddImmutableUnidirectionalMany.jet).
Java test: Very long list, will be anything with String outputString = ""; in the function toString(), AssociationSortedWithNameSpace_Student.java.txt, ClassTemplateTest_Import.java.txt, OptionalOneToMStarTest_Many.java.txt. There may be others that do not contain the outputString that will be changed.
Php templates: association_SetOptionalOneToMandatoryMany
Php tests: OptionalOneToMStarTest_Many.php.txt

This should be in a pull request by mid-Tuesday, or hopefully later today.

Add the Php Umple templates to the repository in the new folder UmpleToPhpTl. Will NOT delete the existing UmpleToPhp, and will default to using them in the build.

This will be a testrun for the other languages, while still allowing people to make changes to Java/Ruby.
Will outline how can get the main build to use the generated code from UmpleToPhpTl instead of UmpleToPhp, and will get the build to generate the Umple templates in a full build as well.

Upload my JETToUmple converter. It is still a work in progress, but it does have plenty of tests.

The converter is written in Umple (with Java for the main code), so it can be added to part of the build process.
I will probably add it as a new repository in Umple, although it is similar to the Umplificator so could make sense to put it in the main repo.

Upload my JETToUmple converter. It is still a work in progress, but it does have plenty of tests.

The converter is written in Umple (with Java for the main code), so it can be added to part of the build process.
I will probably add it as a new repository in Umple, although it is similar to the Umplificator so could make sense to put it in the main repo.

I'd like to put a voice forward to having it in it's own repository. This was discussed at length in #714.
Generally, this is an excellent thing to be changing. :+1:

Regarding directories to put things:
We should keep UmpleToPhp, UmpleToRuby, UmpleToJava, UmpleToSDL, UmpleToSQL and any others  at the top level (we will not touch UmpleToCpp)
inside these we should have

An UmpleTLTemplates directory populated with .ump files that have the templates (the directories called 'templates' would hold the Jet until we delete them.
A src-gen-UmpleTL directory that would have code that is generated from these templates. In time we wouldn't have to keep that code as it could be generated without external dependencies on every build, but for initial bootstrap we would keep it for a while
The src directory in these would temporarily co-exist. The system could be built from either.

I think the rest of the build would work as it does now ... the src would be copied to cruise.umple/src-gen-jet (which would be later on renamed src-gen-umple).

Ok, I will use that directory structure, and add the converter in a new repository.
For my first pull request, will just be removing the main Java tab, which I had mentioned earlier, and ensuring that the Php tests will be passed with both JET and Umple's version of PHP. I will add the additional changes for Java later, once we have fixed any issues that occur with PHP and are about to switch to Umple for Java and Ruby.
This will reduce the time it takes for me to do this commit and get the php umple templates into the repo.

I have set up an alternative line in the build to allow the php code generation to use src-gen-UmpleTL instead of the JET src. As well, I have also added in an example of how could compile the php templates with Umple in the full build.
Some changes will need to be made to the compiling of the php templates, since they are currently compiled after the templates are copied, due to there not being any existing Umple compilation before the templates are copied. This is just meant to be a test of concept.
I am currently testing if there is any significant speed change when switching out php, and will do a pull request once I have check that there isn't any.

Would this be a good time to remove the generated code from version control? Or do we need it for bootstrapping?

It will be removed in a discrete step after a short while. That is the plan. I want to get all the code into UmpleTL, the build switched, and a release done first.

I compared the running time when running with the JET templates and the Umple templates and there isn't really any difference. Will submit the php changes as a pull request momentarily.
The memory usage should be examined, since Umple does by default have the templates be static instead of member variables. Although Umple does reduce the number of strings it stores, since it doesn't write out duplicates.

Since the php Umple template worked fine from the previous pull request, I will now be replacing the JET templates for Php with the templates in Umple.
After that, I will try to do the same with Ruby this week, and then finish up the other templates (other than Cpp due to there being a different version for Cpp available and Java, due to others working on it still). Needing to wait for Java doesn't really matter though, since converting it will take the most time, since the generated code it creates is the most complex, and it creates multiple functions in one template (which they are not designed to easily allow).
I will try to also upload the converter to a new repo in Umple this week.
Please note though that I will be unavailable for most of this weekend, which is why I will need to do some of the changes early next week.

Should I completely remove the JET templates for php? Think it would probably be best to remove them if we will not be using them for the build.
And if so, should I put the php umple templates in the folder templates, or leave them in UmpleTLTemplates?
For now, I will leave the cruise.umple/src-gen-jet/ folder as it is (although will remove the Php compiled template from it) until all of the templates have been switched over from JET. Once that happens, will rename it to be src-gen-UmpleTL or something similar.

I want to remove them in a separate step after the release. Reason: People may be interested in doing a comparison. I will put this in the release notes.

leave the UmpleTL templates in UmpleTLTemplates ... it makes it clearer.

Ok, sounds good. I'll do the pull request switching to php then.

For the Ruby and SQL templates, should I do an initial setup commit like with php or just switch right into compiling them from Umple templates?
For Ruby, I know there are some differences between the JET and Umple outputs, which I am not able to fix in JET. Are all extra spaces on lines.

Can you post a couple of samples of the Ruby differences, just so we can assess what the stylistic differences are. Once we accept, then you can do a full conversion of the Ruby and SQL in one step.

There are a few different types of the differences, so will post an example for each:

Ones like Ruby implementation test ManyToMNTest_Many.ruby.txt, where in the constructor, they have the line (or something very similar):

raise "Unable to create Mentor, must have 3 to 4 @students" unless did_add_students

which has a space at the very end. The Umple templates do not have the extra space.

In the test ClassTemplateTest_Attributes.ruby.txt, there were a few functions of the form:

   def Mentor::get_with_id(a_id)
     @mentors_by_id[a_id]
   end
   def Mentor::has_with_id?(a_id)
     get_with_id(a_id) != nil
   end
   def get_p
     @p
   end

when compiled with JET. Umple will add blank lines between the functions.

Some tests like what happened with Java, where there was extra space added between function:

   end
  // Has two spaces. Occurred in Java as well
   def delete

One instance where a line had a tab instead of spaces. Needed to change the tab to 4 spaces to fit in with the rest of the generated code.

OK fine. Go ahead

On second thoughts ... I woke up thinking about the case of the missing blank line between functions.in Ruby. I think it would be much nicer to keep those blank lines. (I don't care about the other minor differences)
@Diusrex , is the problem simply that your converter automatically results in templates that do not emit the extra line between functions? Or is it somehow that it is hard to get UmpleTL to add that extra blank line.
I think the optimum solution would be to keep the blank lines, so if it is the former problem, can we not manually adjust the templates to retain the blank line?

Ok, I just figured out the issue for the JavaSpecGenerator. For those that don't know, the Umple converter would, when converting some of the tests in testbed/src-gen-umple/cruise/associations/specializations/, output lines with the text You forgot to include specializationSkip.jet.
The issues wasn't the Umple templates, but instead the SpecGenerator was badly created. If you look at line 2603-2615 in the generator, you will see that the function append, and thus appendln will not actually append to the given buffer. Instead, the code in the append was overwritten by JET, since it was the last function in the file.
So the reason the Umple failed was because it was actually running the append/appendln as expected.
By adding the function:
// This method will have the JET stuff inserted into it
private void genHere() {

  }

the JET compiled and had the same error. However, everything else seemed to pass. The failure would occur from line 4689, which prints out the 'You forgot to include '.
My recommended fix to this would be to add the lines:
      else if (includeFile == "specializationSkip.jet")
      {
        %><%@ include file="specializationSkip.jet"%><%    // TODO?
      }

right before
     else if (includeFile != null)
      {
        appendln(stringBuffer,"You forgot to include {0}",includeFile);
      }

since that is how this appears to be fixed in other parts.
As well, the file association_SetOptionalNToMany.jet appears to have the same issue, so will need to handle it the same way as specializationSkip.jet (if try to include association_SetOptionalNToMany.jet, the tests will fail due to it needing unavailable/unset variables..
After applying the fixes for the files specializationSkip.jet and association_SetOptionalNToMany.jet,
Of course, this could also be fixed by keeping the append/appendln not actually adding anything, but that doesn't seem very intuitive/reasonable. They are used over 250 times in the JavaSpecGenerator.java.

OK, so I assume you have a path forward.
In the above your sentence "After applying the fixes for the files specializationSkip.jet and association_SetOptionalNToMany.jet," trails off. I agree that keeping the append/appendln not actually adding anything is not good.

Oh oops:
After applying the changes, all of the tests passed.

Fabulous! So let me know the timetable for the PR then.

Just submitted a pull request for the fix to the append/appendln. Once that goes through, should be able to follow quickly with the Java pull request.

I saw it. Will merge shortly. Thanks.

Merged. Thanks. I am going to do a PR and merge later to delete the old C++ too. That should not conflict with our PR for the java templates.

Ok, I will be submitting the PR with:

UmpleToJava Umple templates
Build defaulting to using JET, but with some comments to explain how to switch.

The build will fail on 19 tests.

OK. You say the build will fail on 19 tests ... hmm. I am a little confused. I want to do a release now but need the build passing. When you say it fails on 19 tests, do you mean if you switch?

Ignore last comment

@TimLethbridge Ok, what do you want me to do right now?
All of the changes to UmpleTL are in (other than building using them), but I can enable that, and delete everything else related to the templates, right now.

I am taking care of this final conversion step

That's what I had figured. Will upload the rough part of my converter tomorrow, as well as do any documentation updates I need to.

Super. It was easier for me to do the two releases back to back tonight; then people can get back to work with all the Jet gone as of tomorrow!

Conversion is complete. We will close this issue once @diusrex commits the code for the converter

I will upload the converter tomorrow. Spent more time working on the readme and other class assignments than I had thought I would. Will try to do this early, since will be getting my wisdom teeth removed Thursday, and so will be unresponsive for much of the (long) weekend.

Ok, I have committed the converter to the repo https://github.com/Diusrex/JETToUmpleTL. I am unable to create a new repo in the Umple organization, so someone will need to create that and import the converter in.

@Diusrex (Just a personal preference) I think it would be better to write each class in a different file (like Java) and use 'use` to connect them together. Of course, there is no issue with the way you wrote. You could put some small classes inside the same file as well.

@vahdat-ab I was actually planning to split up most of the classes into different files. I will be doing a refactoring of it in the next few weeks before the end of the term (as well as implementing some of the missing features). I haven't split them up yet because the classes may change quite a bit, depending on how I split everything up.

@Diusrex Give me temporary ownership rights and I'll add it to the org. :)

@Nava2 I requested an ownership transfer to you.

Should be done, now.

@Nava2 Thanks for that, and for fixing the list formattting too.

Bravo. I am going to close this issue ... work on the converter will go on, indefinitely, but issues should be raised now on that sub project's own issues list I think.

@TimLethbridge

issues should be raised now on that sub project's own issues list I think.

Should that be the case? As we get more and more projects under the umbrella, should they all have issue pages distinct from the main page? Or should we just use labels.
I'm more for having issues in one place with labels. Everything to do with the "compiler" would be under one page while all "green field" projects would be under their own.
This is 100% an opinion piece, just wanted to mention it. :relaxed:

Hmmm. the pattern user:umple in a general issue search will locate all issues in the umple team. But I see your point. This would need to be documented in the Readme.md though if we are to use the umple/umple issues list

My mind falls to "cognitive load" of thinking about which issue belongs to which. Also, cross-repository issues could be problematic. That being said, I may be making up an edge case that wouldn't happen too often.

authors: Diusrex Nava2 SultanEid TimLethbridge ahmedvc vahdat-ab

repo: umple/umple


text:
Fix Traffic Lights B UmpleOnline Example

Description
This PR fixes the Java compilation issue described in issue 953 . The "Traffic Lights B" UmpleOnline example now uses the state machine setter methods to change the state of its state machines. The timer values in the example have also been converted into seconds. I removed the "@@@skipcompile" and "@@@skiprubycompile" directives because both issue 694 and 695 have been fixed.
Tests
No additional tests were added for this fix. I confirmed that the changes passed using
"ant -Dmyenv=local -f build.exampletests.xml allUserManualAndExampleTests".

Thanks @jblang94


text:
Wrong leading spaces/identation in yaml/script parsing?

spot --version
spot v1.7.0-33fac8b-2023-06-06T00:48:21Z

  - name: prom_pass
    commands:
      - name: pass
        script: |
          cat << EOF > /etc/prometheus/prometheus.web.yml
          basic_auth_users:
            admin: $PASS
          EOF

$ cat prom.yml | yq '.tasks[2].commands[0].script' | sed 's/"//g' | sed 's/\\n/\n/g'

cat << EOF > /etc/prometheus/prometheus.web.yml
basic_auth_users:
  admin: $PASS
EOF

spot -p prom.yml --dbg --dry

[s2 s2.hidden.tld:22]  ! command script /tmp/.spot/spot-script3829472563
[s2 s2.hidden.tld:22]  > #!/bin/sh
[s2 s2.hidden.tld:22]  > set -e
[s2 s2.hidden.tld:22]  > cat << EOF > /etc/prometheus/prometheus.web.yml
[s2 s2.hidden.tld:22]  > basic_auth_users:
[s2 s2.hidden.tld:22]  > admin: $PASS
[s2 s2.hidden.tld:22]  > EOF

There is no leading spaces in admin: $PASS line and file created by this script does not contain them too which leads to wrong yaml config.

Yeah, this is expected. We are stripping leading spaces intentionally. I have not seen a use case where spaces are essential, but yours indicates the opposite. I'm not sure what the best approach is here - from one hand, we want to strip all the yml-related spaces in most of the cases, but sometimes we need to keep them

Can not imagine any reason to strip leading spaces from multiline yaml string. Are there any examples where it's better to do it?

oops, edited your comment by accident, planned to reply

I do use a lot of code with cat << EOF >  construction with preformatted files. There are number of ways to strip leading spaces in HEREDOC blocks if needed (like cat <<-EOF) so why to strip more of code, supposed to be run directly with sh/bash ?

see above. I'm not sure if my cleanup makes much sense in the context you provided, let me think about it and see what would be the negative side effects if we drop the stripping

 script: |
   cat blah
   echo 123
    ls -la /srv

This looks like human mistake and spot looks designed to be simple thing to run tasks in parallel technically well so unexpected "smart" features are really unexpected (and worse - undocumented)
Any reasonably expected editor will use mono font, so extra space should be clearly visible.

and, btw, this example code is correct multiline yaml string and it will be correctly run as s script.

May be the good example is
multiline: |
        many spaces at beginning of first line
  two spaces as expected

the correct way to write multiline yaml string here is:
multiline: |2
        many spaces at beginning
  two spaces as expected

so may be referencing https://yaml-multiline.info/ and some more examples and/or rfc could be usefull/reasonable in docs.

sure, good idea. If you can add examples and references to docs - it will be great

authors: knutov umputun

repo: umputun/spot


text:
sql plugin files types question

Hi. Does this plugin works only for *.sql files or is it also capable of formatting inline sql in javascript/typescript string, literal tag (i.e. sql`...`)?

Maybe you mean https://github.com/ruimarinho/sql-tag

Maybe you mean https://github.com/ruimarinho/sql-tag

H, yes, thanks for the response. That was exactly my question regarding TS files. That or other (chosen tags) but also normal string literals (why not, if you can see that given string is an SQL query).
From what I can see this plugin is working for SQL related file types so not sure if that would be even in scope.
As this is more complicated with finding SQL in syntax of specific language where there could be strings with expressions that might not be direct correct SQL, but you would like to format them anyway i.e. TS string literal: select ${cols} from ${tab}${whereWithConditions}.
Was looking for something more robust than https://www.npmjs.com/package/eslint-plugin-sql which is quite buggy and unmaintained. It is using eslint to parse ts files. I know prettier is doing it a little differently.

This is a good-to-have feature request, it requires to extends babel and typescript related parsers.
But it's not in high priority to me, so it would be great if you can raise a PR for it.
I'd like to offer some help if you need.

How html tag work would just be helpful.

Thanks for the encouragement and the kind offer but definitely won't have a capacity to dedicate time here :)

Then no one would offer any effort here.

authors: JounQin ssukienn

repo: un-ts/prettier


text:
Receiver code issue

C:\Users\mclacqui\AppData\Local\Temp.arduinoIDE-unsaved2024819-12280-ld9coh.lcqn\sketch_sep19a\sketch_sep19a.ino: In function 'void setUpPinModes()':
C:\Users\mclacqui\AppData\Local\Temp.arduinoIDE-unsaved2024819-12280-ld9coh.lcqn\sketch_sep19a\sketch_sep19a.ino:161:3: error: 'ledcSetup' was not declared in this scope
161 |   ledcSetup(rightMotorPWMSpeedChannel, PWMFreq, PWMResolution);
|   ^~~~~~~~~
C:\Users\mclacqui\AppData\Local\Temp.arduinoIDE-unsaved2024819-12280-ld9coh.lcqn\sketch_sep19a\sketch_sep19a.ino:163:3: error: 'ledcAttachPin' was not declared in this scope; did you mean 'ledcAttach'?
163 |   ledcAttachPin(enableRightMotor, rightMotorPWMSpeedChannel);
|   ^~~~~~~~~~~~~
|   ledcAttach
C:\Users\mclacqui\AppData\Local\Temp.arduinoIDE-unsaved2024819-12280-ld9coh.lcqn\sketch_sep19a\sketch_sep19a.ino: In function 'void setup()':
C:\Users\mclacqui\AppData\Local\Temp.arduinoIDE-unsaved2024819-12280-ld9coh.lcqn\sketch_sep19a\sketch_sep19a.ino:184:28: error: invalid conversion from 'void ()(const uint8_t, const uint8_t*, int)' {aka 'void ()(const unsigned char, const unsigned char*, int)'} to 'esp_now_recv_cb_t' {aka 'void ()(const esp_now_recv_info, const unsigned char*, int)'} [-fpermissive]
184 |   esp_now_register_recv_cb(OnDataRecv);
|                            ^~~~~~~~~~
|                            |
|                            void ()(const uint8_t, const uint8_t*, int) {aka void ()(const unsigned char, const unsigned char*, int)}
In file included from C:\Users\mclacqui\AppData\Local\Temp.arduinoIDE-unsaved2024819-12280-ld9coh.lcqn\sketch_sep19a\sketch_sep19a.ino:1:
C:\Users\mclacqui\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.1-b6b4727c58\esp32/include/esp_wifi/include/esp_now.h:157:54: note:   initializing argument 1 of 'esp_err_t esp_now_register_recv_cb(esp_now_recv_cb_t)'
157 | esp_err_t esp_now_register_recv_cb(esp_now_recv_cb_t cb);
|                                    ~~~~~~~~~~~~~~~~~~^~
exit status 1
Compilation error: 'ledcSetup' was not declared in this scope

probably need to change your ESP32 board from 3.0.x to 2.0.17, as it is what I have done


text:
Fix extractSrcToDir example in README adding null argument

I added null argument to the example.

Thanks a lot!

authors: csalazar kayhuba

repo: unblu/js-source-extractor

license: ISC


text:
🛑 Main site is down

In 58808a7, Main site (https://www.undp.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Main site is back up in 9033323.

repo: undp/uptime-monitor


text:
sidebar navigation permissions

This is also mentioned in this issue #230  and issue got closed with the fix #234, But the issue is still there.
I am in v0.20.1

Confirmed 0.20.3 works great, appreciate for your help and support

repo: unfoldadmin/django-unfold


text:
Core fnr-text improvements

Upon reviewing the code for fnr-text I've noted many improvements that could be made.
TL;DR: the fnr-text needs to be refactored into 2 layers: A core module that is well-typed and is safe to make all the assumptions that are necessary. A second module that is the user interface for the library that provides a user-friendly interface.
A few first highlevel observations are the following:

an architecture diagram for findr needs to be constructed (if one already exists then it needs to be included in the typedoc)
The types defined need to be revisited. There are many refinements that need to be made (name changes, type refinement, and EDSL construction) to make this library production ready.
Fully lean into the typing system that TS provides. Assume users of your library are going to use TS and if they chose not to then they are need to know they are knowingly going into "the danger zone".  This leads to the next suggestion.
Implement the idea of "parse don't validate" to avoid needing excessive if statements and type-guarding.

In regards to the comments about types above I suggest using a runtime type-checking system like this. I'm not sure which one is the "best" but it would remove the need to do this manually - and would improve API and code quality in the future.

In regards to refining the types I've found a pattern-matching library. Coming from an FP background pattern-matching signifigantly simplifies code and reduces errors

This PR is getting to big. I'm splitting it up into:

#35
#34

repo: unfoldingWord/findr


text:
Show Bible Ref navigation in app bar according to if book is opened - and which book is current active

The Bible Ref navigation in the app bar does not make sense to be visible, until there is a book opened.
Once there is a book opened, then this navigation needs to be showing the position in the current active window
Note:
There is a need to keep a reference to which book is the current active window (probably in the AppContext) and change the Bible Ref navigation in the app bar accordingly

@abelpz can you please review this issue

Currently, In develop, there is no navigation bar in the blue header when the user logs in and then when a book is added, Navigation bar shows that book.

Looks good in v1.0.0 build 0168902 QA.

authors: elsylambert larsgson

repo: unfoldingWord/gateway-translate


text:
🛑 Piped is down

In e90fcb1, Piped (https://piped.unforest.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Piped is back up in 3bd8c0a after 11 minutes.

repo: unforest/uptime


text:
🛑 Nitter is down

In 3f69f7e, Nitter (https://nitter.unforest.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Nitter is back up in 4adc054 after 30 minutes.


text:
🛑 Unforest is down

In d3b7df9, Unforest (https://www.unforest.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Unforest is back up in f53da23 after 12 minutes.


text:
🛑 Piped API is down

In 8c7ee46, Piped API (https://pipedapi.unforest.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Piped API is back up in c27ac20 after 24 minutes.


text:
🛑 Piped is down

In 4ebaaea, Piped (https://piped.unforest.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Piped is back up in d26e7eb after 11 minutes.


text:
🛑 Piped is down

In d5e4e38, Piped (https://piped.unforest.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Piped is back up in 2fb4fe1 after 14 minutes.


text:
🛑 Piped API is down

In 752b24c, Piped API (https://pipedapi.unforest.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Piped API is back up in 07f23fd after 23 minutes.


text:
Map #52 WIP

For #52 WIP

This now mimics the visual behaviour of SFVC more closely:

repo: unisdr/undrr-mangrove


text:
Fix X509 Certificate reading error

When the X509 certificate was read an extra undefined was appended to the data.
The last .replace() was missing the substitution string parameter, which was defaulted to undefined.

PTAL

LGTM

Are we going to upstream this?

Yes, I am. Unfortunately, I'm out of step with the PRs. I submitted a PR from a different fork. I'll get it back in sync.

authors: akeating duane-unitive mhfrantz


text:
Unity-Py publication to Pypi

create workflows in github for unity-py publication to pypi

Added as part of #36

@mike-gangl is this Done?

has been done for a while!

authors: mike-gangl rtapella

repo: unity-sds/unity-py


text:
Add Support for @activeOnSubPaths to Link component

Per #308 this adds a named arg @activeOnSubPaths to allow links to be considered active when child routes are the current URL.
The new @activeOnSubPaths arg defaults to false to retain existing active behavior without a breaking change. In a major release it may make sense to default this to true.

In a major release it may make sense to default this to true.

I don't think the default will change, because sometimes you do want a differentiation between foo.index and foo.bar, which are foo/ and foo/bar respectively.
But this change is great! thanks for working on it!
is the PR intended to still be draft?

is the PR intended to still be draft?

I was still checking that the docs rendered and giving some 👀 after coffee.
Gonna check the ternary.
I'm :/ on the query params state not having a test right now so gonna work on a test state for that to go along with the includeActiveQueryParams render test

authors: NullVoxPopuli rtablada

repo: universal-ember/ember-primitives